Quais são os recursos necessários para a Orientação a Objetos?

Estou apenas imaginando, quais são exatamente os recursos que uma linguagem ou biblioteca deve fornecer para que seja definida como 'Orientada a Objetos'. A Orientação a Objetos é algo que pode, mais ou menos, ser alcançado em qualquer linguagem de programação de uso geral com recursos decentes? Ou é algo que só pode ser alcançado em idiomas que anunciam especificamente que suportam a Programação Orientada a Objetos?

Por exemplo, observe o seguinte código C:

SDL_Surface* screen = SDL_SetVideoMode( 640, 480, 16, SDL_HWSURFACE);
SDL_FreeSurface( screen );

ou o código discutido aqui .

Agora, o código acima não usa herança, polimorfismo de tempo de execução (?), Funções virtuais etc.

A Orientação a Objetos está simplesmente escrevendo código que se baseia em estruturas de dados que podem ser criadas e destrutíveis, como objetos, classes, estruturas etc., que não exigem nenhum padrão ou recurso especial fornecido pela Linguagem de Programação ou por uma biblioteca ?

Segundo Alan Kay, que inventou o termo "orientação a objetos",

OOP para mim significa apenas mensagens, retenção e proteção local e ocultação de processos estatais e vinculação tardia extrema de todas as coisas. Isso pode ser feito no Smalltalk e no LISP. Possivelmente existem outros sistemas nos quais isso é possível, mas eu não os conheço.

As mensagens (conforme implementadas no Smalltalk) são um conceito comparável ao polimorfismo, mas bastante mais poderoso (pelo menos do que o tipo de polimorfismo suportado por C ++ ou Java). Isso pode ser feito em todos os idiomas, mas é bastante doloroso se não for suportado diretamente pelo idioma. Basicamente, isso significa que os objetos podem se enviar mensagens contendo qualquer coisa, o amd pode reagir como quiserem e receberem mensagens. Para dar suporte total às mensagens, é necessário que os objetos reajam de maneira flexível às mensagens sem enumerá-las no código-fonte (que é basicamente o que as definições de método / função fazem).

retenção local e proteção e ocultação de processos estatais - encapsulamento AKA - podem ser feitas por convenção em todos os idiomas, mas isso é trapaça. A retenção local no nível do idioma realmente parece ser o único recurso que todos os idiomas que afirmam compartilhar OO (e muitos que não compartilham) - geralmente existe uma maneira de criar tipos de dados compostos com várias instâncias. A proteção e a ocultação, por outro lado, geralmente são feitas apenas por convenção.

vinculação tardia de todas as coisas - uma escala móvel na qual C está muito longe da visão de Kay (assim como C ++, enquanto Java está muito mais próximo). Pode ser falsificado (consulte COM), mas isso será difícil de usar.

Observe como Kay não menciona herança . No mesmo e-mail que ele escreveu

Não gostei da maneira como o Simula I ou o Simula 67 herdaram (embora eu pensasse que Nygaard e Dahl eram apenas tremendos pensadores e designers). Decidi deixar de fora a herança como um recurso interno até entender melhor

A programação orientada a objetos não trata de recursos de sintaxe, é uma filosofia de codificação e design. Na essência, está o conceito de um objeto , que é um construto que agrupa estados com rotinas para agir sobre ele (ou, dependendo do seu ponto de vista, respostas a mensagens). O outro aspecto importante do OOP é o encapsulamento : agrupando detalhes da implementação em estruturas opacas e conectando-os por meio de interfaces bem definidas. Praticamente tudo o mais na teoria OOP remonta a esses dois fundamentos.

Portanto, qualquer linguagem que possa, de alguma forma, modelar objetos (entidades que contenham dados e código) e encapsulamento pode ser usada para fazer OOP. Por exemplo, em C, você pode usar ponteiros de função para armazenar funções em estruturas e o sistema de arquivos de cabeçalho / origem para realizar o encapsulamento. Não é conveniente, mas é suficiente para fazer POO. Você provavelmente pode até inclinar algo como Haskell ou ML para fazer POO, e eu não ficaria surpreso se alguém pudesse inventar uma maneira de fazer POO em assembléia.

Na prática, porém, uma linguagem pode ser chamada de 'orientada a objetos' se fornecer um conjunto completo de recursos de sintaxe para programação orientada a objetos explícita. Normalmente, isso significa que essa linguagem deve ter: * uma noção de um objeto * uma noção de chamada de método ou passagem de mensagem * uma maneira confortável e direta de controlar o acesso aos membros do objeto * uma maneira confortável e direta de definir interfaces

Conseqüentemente, eu chamaria um pedaço de código de orientado a objeto se ele seguisse os princípios de OOP e usasse a sintaxe disponível de OOP.

BTW., O exemplo de código, provavelmente, faz uso polimorfismo e funções virtuais, embora a sintaxe C não torna óbvia. Não sou especialista em SDL, mas esperaria SDL_surfacepoder representar vários tipos diferentes de superfícies, cada uma com seu próprio conjunto específico de implementações. código, mas a interface (as funções que aceitam SDL_surface*como argumento) permanece a mesma. Assim, ele também implementa o encapsulamento: você não pode acessar diretamente a representação subjacente de uma superfície, precisa passar por funções que sabem como lidar com uma SDL_surface, porque é tudo o que você tem. É um bom exemplo de como você faria POO em C.

Meu entendimento do OO é que o OO é uma maneira de pensar e uma implementação baseada na ideia de que uma tarefa computacional pode ser realizada por um trabalhador (objeto) ou pela colaboração de trabalhadores individuais (objetos) por meio da passagem de mensagens entre esses trabalhadores ( objetos) em tempo de execução. Esse comportamento em tempo de execução requer construções estáticas e dinâmicas sólidas para habilitá-lo.

A sintaxe específica para implementar o OO não é a chave que determina se um idioma é OO ou não. Por exemplo, Smalltalk e C # têm sintaxes diferentes, mas ambos são idiomas OO (em vários graus). A chave é se o idioma fornecido preserva a filosofia (acima) e fornece os meios de implantação necessários.

Quando eu era aluno, aprendi que a programação orientada a objetos se baseia em três pilares:

• encapsulamento ,
• polimorfismo e
• herança .

Uma linguagem precisará suportar esses recursos para ser considerada uma linguagem orientada a objetos.

Observe que isso descreve um conjunto de recursos, em vez de sintaxe . Portanto, se você precisa escrever

type obj; // or type obj = new type;
obj.func(arg);

ou

type* ptr = create_type();
func(ptr, arg); 

não importa.

Portanto, você pode realmente programar de acordo com o paradigma orientado a objetos em C. Mas a linguagem não oferece suporte para isso, o que a torna um exercício bastante doloroso. É por isso que C não é considerado uma linguagem orientada a objetos.

Você pode fazer OO em qualquer linguagem de uso geral decente.

É mais fácil fazê-lo em uma linguagem "OO", porque você tem construções idiomáticas disponíveis e não precisa recorrer a algo como OO em C - o que é possível, mas horrível.

Se as construções OO são fornecidas pela própria linguagem, por sua biblioteca padrão ou por alguma outra biblioteca, não importa muito, pois algumas linguagens (por exemplo, Scala) permitem que as bibliotecas adicionem construções de linguagem para que, do ponto de vista do programador, seja quase impossível distinguir quais coisas são fornecidas pela linguagem principal e quais por uma biblioteca.

Se você observar a variedade de idiomas que foram amplamente aceitos como OO e os que não o fizeram, o teste parece ser o suporte ao polimorfismo de inclusão (também conhecido como polimorfismo de subtipo, mas polimorfismo de inclusão é o termo usado por Cardelli no artigo que me apresentou, e acho que muitos outros, a uma classificação de tipos de polimorfismo). Ou seja, a possibilidade de algumas variáveis ​​terem valores de tipos diferentes e a possibilidade de algumas chamadas serem despachadas para rotinas diferentes, dependendo do tipo de um ou vários valores. Todo o resto esteve presente em idiomas não aceitos como OO ou faltando em idiomas bem aceitos como OO.

As duas outras principais características associadas aos idiomas OO foram fornecidas por idiomas não OO:

• O encapsulamento é bastante bem fornecido pelo Ada83;
• A herança é fornecida por Oberon (Oberon é interessante, Wirth queria fornecer uma linguagem OO com o mínimo de fragmentos possível, mas teve que revisitar sua concepção para obter uma - Oberon-2 é OO).

A orientação do objeto é definida como

• Polimorfismo
• Herança
• Encapsulamento

verifique também as entradas da Wikipedia. esses são os recursos que uma linguagem deve fornecer para que seja definida como orientada a objetos.

considere seu código orientado a objetos se estiver em uma linguagem de programação orientada a objetos. mesmo se você escrever algo que parece ser processual, ele estará agindo sobre métodos em objetos de classes usando polimorfismo via encapsulamento [talvez] :)

em relação à sua última pergunta, a resposta é provavelmente. sim. orientado a objeto é basicamente apenas agindo sobre métodos em objetos e passando esses objetos como parâmetros.