Definição formal para o termo "linguagem OO pura"?

Não consigo pensar em um lugar melhor entre os irmãos SO para fazer essa pergunta. Originalmente, eu queria perguntar "O python é uma linguagem OO pura?" mas considerando problemas e algum tipo de desconforto que as pessoas experimentam ao tentar definir o termo, decidi começar por obter uma definição clara para o termo em si.

Seria bastante justo começar com a correspondência do Dr. Alan Kay, que cunhou o termo (observe a inspiração na analogia biológica para células ou outros objetos vivos).

Existem as seguintes maneiras de abordar a tarefa:

1. Faça uma análise comparativa listando linguagens de programação que podem exibir (ou deixar de fazê-lo) certas propriedades únicas e suficientes para definir o termo (embora Smalltalk, Scala, Java e assim por diante - sejam exemplos possíveis, mas o IMO dessa maneira não parece realmente completo nem frutífero )
2. Dê uma definição formal (ou próxima a ela, por exemplo, em estilo mais acadêmico ou matemático).
3. Dê uma definição filosófica que se baseie totalmente no contexto semântico da linguagem concreta ou em uma experiência de programação a priori (deve haver alguma chance de explicação bem-sucedida da comunidade).

Minha versão atual: "Se uma certa linguagem de programação ( formal ) que pode ( gramaticalmente ) diferenciar operações e operandos, bem como inferir sobre o tipo de cada operando, se esse tipo é um objeto (no sentido de POO) ou não, então chamamos essa linguagem é uma linguagem OO, desde que exista pelo menos um tipo nessa linguagem que seja um objeto. Por fim, se todos os tipos de linguagem também forem objetos, definimos que essa linguagem é uma linguagem OO pura (forte) ".

Gostaria de receber qualquer possível melhoria dele. Como você pode ver, acabei de tornar a definição dependente do termo "objeto" (geralmente totalmente referenciado como classe de objetos).

[EDITAR]

Além disso, eu uso (felizmente bem entendido) a noção de um tipo como nas linguagens digitadas. A programação de tipos de dados ou programação orientada a tipos não é apenas uma interpretação sintática (do texto do programa, ou seja, como tratar certos valores de literais e variáveis ​​de dados - algo que evolui para a segurança de tipos), mas pode ser atribuída à gramática da linguagem e estudada de maneira formal (usando lógica matemática) como os chamados sistemas de tipos . Observe que exigir que um sistema de tipos específico tenha o chamado tipo universal é uma das maneiras de definir a pureza da linguagem OO (existem maneiras de expandir isso semanticamente).

NB

como responder :

• ajuda se você especificar um livro ou uma referência que suporte / explique sua compreensão de terminologia e conceitos (geralmente uma boa definição cobre ou faz referência a todos os conceitos dependentes, exceto os elementares).
• se possível, indique uma categoria recuada da sua resposta / definição, se não estiver claro o contrário (veja acima: 1 - por exemplo de linguagem, 2 - lógica matemática, 3 - descrição técnica e filosofia de programação)
• a classificação é importante (e também porque o termo OO puro é incluído no termo OO) ao responder tentar desmistificar elementos do paradigma OO de outras metodologias conhecidas (e de nenhuma maneira confundir / sobrepor-los, por exemplo, elementos tipicamente da programação modular podem ser cobertos / incorporada à programação OO): tente distinguir OOP de (incluindo ou fazer parte de) programação funcional, programação lógica (especialmente altamente especializada), tipos de dados Abstarct (ADT), modular, metaprogramação (genéricos e tempo de macroexpansão do LISP), Contratos (por exemplo, Eiffel), orientado a aspectos (AO), ( são claras as diferenças entre a classificação declarativa e a funcionalidade, bem como as definições históricas da estrutura de Dijkstra)

na dificuldade de fornecer uma definição formal : surpreendentemente, é muito fácil fornecer uma descrição matemática do OOP na forma de um determinado sistema lógico (formal) (provavelmente baseado no tipo) e definir um conceito após o outro. Pode-se até tentar fazer algo mais prático aplicando esse formalismo a tipos de verificação de segurança ou aspectos de design de nova linguagem do que apenas entretenimento ou exercíciosabstratos(também procure formulação de OOP em Teoria Intuicionista de Tipos , tipos dependentes , independentemente, em formalismos FOL como cálculo lambda e apenas usando a teoria das categorias). Um ponto principal aqui é que sem surpresatais formulações IMO são fortemente tendenciosas (falhas) pelo entendimento provavelmente incompleto inicialmente de OOP (em engenharia da computação) e acabam sendo quase inacessíveis posteriormente (dificilmente contribuindo para trás no mundo da programação - talvez, exceto que certa porcentagem encontre aplicativos de volta ao mundo formal sendo integrado em idiomas populares ).

Então, sim, é difícil fornecer exatamente uma definição "boa", não apenas uma definição. Mas sou positivo em perguntar isso aqui por causa de sua experiência e envolvimento direto, pessoal.

OO, de acordo com Alan Kay, tem tudo a ver com a transmissão de mensagens, e é isso. Você verá que qualidades como polimorfismo e encapsulamento são realmente derivadas da passagem de mensagens.

Agora, essa postura é de fato muito extrema, porque basicamente significa que apenas o Smalltalk e os idiomas se qualificariam.

Eu acho que você pode definir OO como construindo seu sistema em entidades, que encapsulam completamente seu estado e são trocadas devido a suas qualidades polimórficas inerentes. Alguém poderia argumentar que uma linguagem puramente OO garante que essas duas qualidades principais sejam sempre atendidas. O que torna as linguagens OO "impuras" seriam mecanismos que permitam a criação de construções que não atendem a esses critérios, como as possibilidades de:

• declarar campos públicos
• declarar variáveis ​​que só podem conter instâncias de uma classe específica e suas subclasses (ou seja, variáveis ​​devem ser digitadas em interfaces, que é o que os objetos biológicos se comunicam na anologia de Kay), que são ainda mais restritas se a classe em questão for final, como que deixa ainda menos espaço para o polimorfismo
• declarar primitivas

Então, novamente, a pureza da linguagem IMHO é mais uma fraqueza do que uma força. OO não é uma bala de prata. Nenhum paradigma é único.

Eu abordaria isso definindo-o como uma linguagem que usa construções OOP e nada mais (da mesma maneira que uma linguagem FP pura usa funções puras com dados imutáveis ​​e nada mais).

Em particular:

• Toda entidade em que seu programa opera é um Objeto de primeira classe - ou seja, sem primitivas, sem ponteiros, sem matrizes etc.
• A única coisa que você pode fazer com um objeto é chamar um método (potencialmente polimórfico) (== enviando uma mensagem). Não existem outras operações.
• Todos os dados são encapsulados - ou seja, sem acesso ao campo público, você deve usar métodos em um objeto
• Se você possui funções de primeira classe, elas também devem ser objetos - portanto, você precisa fazer algo comofunctionObject.call(param1,param2)
• Sem variáveis ​​globais - se você quiser algo assim, precisará usar um objeto para representar o ambiente global atual, por exemplo, environment.getValue("myThing")ou colocar a variável em um objeto de classe

Observe que isso ainda deixa várias opções em aberto:

• Modelos de objetos baseados em classe vs. modelos baseados em protótipo
• Como a herança é implementada (se houver)
• Se você tem despacho único ou múltiplo nos métodos
• Se seus objetos são digitados estaticamente ou dinamicamente
• A sintaxe exata usada para chamadas de método (por exemplo, você pode ter algum açúcar sintático para getters / setters etc.)

A discussão sobre as chamadas linguagens OO sempre foi um pouco do lado do cérebro. Ou seja:

"Alguém me disse que a linguagem X é OO; portanto, a linguagem X é igual a OO; então, toda linguagem que não possui os recursos da linguagem X não pode ser OO. E, como estou escrevendo meu código na linguagem X, tudo o que faço é OO. "

O termo design orientado a objetos se resume a três coisas:

1. Design modular com objetos autônomos que não conhecem informações desnecessárias sobre o restante do programa, também conhecido como acoplamento flexível possível.
2. Encapsulamento de dados dentro de objetos para impedir o acesso externo, intencional e acidental.
3. Dependências claramente especificadas entre objetos. Para obter acoplamentos soltos, mas também para facilitar a manutenção e expansão do programa.

1) é puro design de programa, pode ser alcançado em qualquer linguagem de programação. No entanto, alguns idiomas têm recursos úteis, como classe / estrutura e palavras-chave privadas.

2) é principalmente o design do programa, embora não possa ser totalmente alcançado sem o suporte ao idioma, pois você precisa de mecanismos de linguagem como privado / estático para proteger contra uso acidental.

3) é principalmente design de programa. Normalmente, existem três dependências diferentes: "o objeto X contém o objeto Y", "o objeto X é um tipo de Y" e "o objeto X interage com o objeto Y". Existem muitos recursos de linguagem para ajudar com essas dependências: herança / polimorfismo, classes base abstratas e assim por diante.

Agora, se olharmos para o acima, podemos ver que você quase não precisa de nenhum recurso de idioma para escrever programas OO. Os recursos apenas tornam muito mais fácil.

Os objetivos acima não podem ser alcançados usando-se uma lógica reversa enlameada: apenas porque você usa a palavra-chave class, seu programa não recebe automaticamente um design modular. Só porque você usa herança, isso não significa automaticamente que suas dependências de objeto fazem sentido. Um idioma com recursos OO ainda permitiria coisas como class TheWholeBloodyProgram"Animal herda gato".

Infelizmente, o tópico sobre o bom design de programas orientados a objetos raramente é mencionado nesse tipo de discussão. Os programadores com lavagem cerebral só olham para a sintaxe e gritam coisas como, por exemplo, "C ++ tem tipos de dados primitivos para que seu programa C ++ não seja OO", então eles escrevem um programa horrível em sua própria linguagem favorita, sem usar nenhuma dica de design do programa, o que for.

Para responder à pergunta: muito poucos, se houver algum idioma, oferecem suporte ao design adequado do programa OO. Descobrir quais idiomas que possuem certos recursos relacionados ao OO são irrelevantes, desde que o programador não saiba o que significa design orientado a objetos. Um programador que afirma que certas linguagens são orientadas a objetos provavelmente não entendeu o conceito de OO como um todo. Pergunte ao possível programador de OO como ele cria programas de OO. Se a primeira coisa que eles fazem é começar a gritar palavras-chave no idioma, você pode assumir com segurança que elas não conhecem o design do OO.

Talvez exista alguma ferramenta sofisticada de alto nível UML-ish muito acima do código-fonte bruto, que força o programador a escrever apenas programas com um bom design orientado a objetos, mas duvido. As melhores ferramentas de design para a programação OO provavelmente ainda são o cérebro humano e o senso comum.

Não, não existe uma definição formal ou mesmo útil, e nunca haverá. Para algumas pessoas, OOP significa "Classe base universal" e "Deve usar a semântica de referência, melhor com um coletor de lixo" - e você pode até ter dúvidas sobre a sintaxe, uma das coisas menos relevantes já inventadas.

Por fim, primeiro, você deve responder à pergunta "O que é um objeto?". Os mais mesquinhos insistirão em herdar de alguma classe básica universal inútil e serão desnecessariamente alocados em um coletor de lixo para se qualificar. Mas eu prefiro uma definição muito mais útil. O objetivo do OOP é ter alguns dados e algumas funções que você pode chamar nesses dados. então

• Um objeto contém algum estado e oferece algumas funções nesse estado.

Nesse caso, até se intqualifica. Afinal, quando você escreve um código de modelo em C ++ que pode aceitar primitivos ou objetos, torna-se difícil argumentar que os primitivos são diferentes de maneira substancial. Não há nada significativamente diferente em Vector v1, v2; v1 + v2;vez de int v1, v2; v1 + v2;(exceto a semântica de inicialização de baixa qualidade, é preciso admitir). Além disso, isso permite que lambdas e essas coisas sejam objetos, como eles mantêm o estado - suas capturas - e oferecem uma função nesse estado, para chamar o lambda.

Felizmente, também podemos classificar ponteiros para liberar funções como objetos, pois ambos mantêm o estado (um endereço) e uma função nesse estado (para chamá-lo). Portanto, uma função livre deve ser permitida - mesmo se você disser que todas as funções livres são, de fato, indicadores globais de funções.

Você pode pensar nisso por exemplo negativo. Java não é uma linguagem orientada a objetos pura, porque também existem tipos primitivos que não são objetos. Estes são números inteiros, duplos, matrizes e assim por diante. Em uma linguagem pura de objetos, a semântica dos objetos está disponível para tudo.

Há também a questão de quanto da linguagem está fechada para modificação, mesmo dentro da estrutura do objeto. Em java, você não pode definir novas subclasses para algumas classes, como String ou Class.

Quais idiomas são puros? O único candidato que vem à mente é conversa fiada.