Então, o que * Alan Kay realmente quis dizer com o termo “orientado a objetos”?

Alegadamente, Alan Kay é o inventor do termo "orientado a objetos". E ele é freqüentemente citado como tendo dito que o que chamamos de OO hoje não é o que ele quis dizer.

Por exemplo, eu encontrei isso no Google:

Eu inventei o termo 'orientado a objetos' e posso dizer que não tinha C ++ em mente

- Alan Kay, OOPSLA '97

Lembro-me vagamente de ouvir algo bastante esclarecedor sobre o que ele quis dizer. Algo ao longo das linhas de "passagem de mensagem".

Você sabe o que ele quis dizer? Você pode preencher mais detalhes sobre o que ele quis dizer e como ele difere do OO comum de hoje? Por favor, compartilhe algumas referências, se você tiver alguma.

Obrigado.

http://www.purl.org/stefan_ram/pub/doc_kay_oop_en

Data: Qua, 23 de julho de 2003 09:33:31 -0800. Para: Stefan Ram [removido por privacidade] De: Alan Kay [removido por privacidade] Assunto: Re: Esclarecimento de "orientação a objetos"

Olá Stefan -

Desculpe pelo atraso, mas eu estava de férias.

Às 18:27 +0200 em 17/07/03, Stefan Ram escreveu:

Caro Dr. Kay,

Eu gostaria de ter alguma palavra oficial sobre o termo "programação orientada a objetos" para a minha página de tutorial sobre o assunto. As únicas duas fontes que considero "autoritativas" são a Organização Internacional de Padrões, que define "orientada a objetos" na "ISO / IEC 2382-15", e você, porque, como dizem, cunhou esse termo.

Tenho certeza que sim.

Infelizmente, é difícil encontrar uma página da web ou fonte com sua definição ou descrição desse termo. Existem vários relatórios sobre o que você poderia ter dito a esse respeito (como "herança, polimorfismo e encapsulamento"), mas essas não são fontes de primeira mão. Também estou ciente de que mais tarde você dará mais ênfase às "mensagens" - mas eu ainda gostaria de saber sobre "orientação a objetos".

Para os registros, minha página de tutorial e mais distribuição e publicação, você poderia explicar:

Quando e onde o termo "orientação a objetos" foi usado primeiro?

Em Utah, pouco depois do dia 66 de novembro, quando, influenciado pelo Sketchpad, Simula, o design do ARPAnet, o Burroughs B5000 e minha formação em Biologia e Matemática, pensei em uma arquitetura para programação. Provavelmente foi em 1967, quando alguém me perguntou o que eu estava fazendo e eu disse: "É uma programação orientada a objetos".

A concepção original tinha as seguintes partes.

• Pensei nos objetos como células biológicas e / ou computadores individuais em uma rede, capazes apenas de se comunicar com mensagens (então as mensagens surgiram logo no início - demorou um pouco para ver como fazer as mensagens em uma linguagem de programação com eficiência suficiente para seja útil).

• Eu queria me livrar dos dados. O B5000 quase fez isso através de sua arquitetura HW quase inacreditável. Percebi que a metáfora da célula / computador inteiro se livraria dos dados e que "<-" seria apenas mais um token de mensagem (demorei um pouco para pensar nisso, porque realmente pensei em todos esses símbolos como nomes para funções e procedimentos.

• Minha formação em matemática me fez perceber que cada objeto poderia ter várias álgebras associadas a ele, e poderia haver famílias delas, e que elas seriam muito, muito úteis. O termo "polimorfismo" foi imposto muito mais tarde (acho que por Peter Wegner) e não é muito válido, pois realmente vem da nomenclatura de funções, e eu queria muito mais que funções. Eu inventei o termo "genérico" para lidar com comportamentos genéricos de forma quase algébrica.

• 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). Por isso, decidi deixar de fora a herança como um recurso interno até entender melhor.

Minhas experiências originais com essa arquitetura foram feitas usando um modelo que adaptei da "Generalização de Algol" de van Wijngaarten e Wirth e Euler de Wirth. Ambos eram parecidos com LISP, mas com uma sintaxe legível mais convencional. Naquela época, eu não entendi a ideia monstruosa de metal tangível da LISP, mas cheguei perto de idéias sobre linguagens extensíveis extraídas de várias fontes, incluindo o IMP de Irons.

A segunda fase disso foi finalmente entender o LISP e depois usá-lo para criar subestruturas muito mais agradáveis ​​e menores, mais poderosas e mais atrasadas. A tese de Dave Fisher foi feita no estilo "McCarthy" e suas idéias sobre estruturas de controle extensíveis foram muito úteis. Outra grande influência nesse momento foi o PLANNER de Carl Hewitt (que nunca obteve o reconhecimento que merece, dado o quão bem e quão cedo foi capaz de antecipar o Prolog).

O Smalltalk original no Xerox PARC saiu do exposto acima. Os Smalltalk subseqüentes são reclamados no final do capítulo História: eles recuaram em direção a Simula e não substituíram os mecanismos de extensão por mecanismos mais seguros, que eram úteis em qualquer lugar.

O que significa "programação orientada a objetos" para você? (Nenhuma introdução de tutorial é necessária, apenas uma breve explicação [como "programação com herança, polimorfismo e encapsulamento"] em termos de outros conceitos para um leitor familiarizado com eles, se possível. Além disso, não é necessário explicar "objeto" ", porque eu já tenho fontes com a sua explicação sobre" objeto "de" Early History of Smalltalk ".)

(Eu não sou contra tipos, mas não conheço nenhum sistema de tipos que não seja uma dor completa, por isso ainda gosto de digitação dinâmica.)

OOP para mim significa apenas mensagens, retenção e proteção local e ocultação de processos estatais e vinculação 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.

[Além disso] Uma das coisas que eu deveria ter mencionado é que havia dois caminhos principais que foram catalisados ​​por Simula. A primeira (apenas por acidente) foi a rota de procedimentos sem dados bio / líquidos que eu segui. O outro, que surgiu um pouco mais tarde como objeto de estudo, era de tipos abstratos de dados, e isso ficou muito mais divertido.

Se olharmos para toda a história, veremos que o proto-OOP começou com o ADT, tinha um pequeno garfo em direção ao que eu chamei de "objetos" - que levaram ao Smalltalk, etc., - mas depois do garfo pequeno, o O estabelecimento de CS praticamente fez o ADT e queria seguir o paradigma de procedimento de dados. Historicamente, vale a pena examinar o sistema de arquivos USAF Burroughs 220 (que descrevi na história do Smalltalk), o trabalho inicial de Doug Ross no MIT (AED e anterior), no qual ele defendia a incorporação de ponteiros de procedimento em estruturas de dados, o Sketchpad (que tinha polimorfismo completo - onde, por exemplo, o mesmo deslocamento em sua estrutura de dados significava "exibição" e haveria um ponteiro para a rotina apropriada para o tipo de objeto que a estrutura representava, etc., e o Burroughs B5000, cujas tabelas de referência de programas eram verdadeiros "grandes objetos" e continham ponteiros para "dados" e "procedimentos", mas geralmente podiam fazer a coisa certa se tentassem buscar dados e encontrassem um ponteiro de procedimento. E os primeiros problemas que resolvi com minhas primeiras coisas em Utah foram o "desaparecimento de dados" usando apenas métodos e objetos. No final dos anos 60 (eu acho), Bob Balzer escreveu um artigo bastante bacana chamado "Dataless Programming", e logo depois John Reynolds escreveu um artigo igualmente bacana "Gedanken" (acho que em 1970) no qual ele mostrou que usando o lamda expressões da maneira correta permitiria que os dados fossem abstraídos por procedimentos. mas muitas vezes poderia fazer a coisa certa se estivesse tentando ir atrás dos dados e encontrasse um ponteiro de procedimento. E os primeiros problemas que resolvi com minhas primeiras coisas em Utah foram o "desaparecimento de dados" usando apenas métodos e objetos. No final dos anos 60 (eu acho), Bob Balzer escreveu um artigo bastante bacana chamado "Dataless Programming", e logo depois John Reynolds escreveu um artigo igualmente bacana "Gedanken" (acho que em 1970) no qual ele mostrou que usando o lamda expressões da maneira correta permitiria que os dados fossem abstraídos por procedimentos. mas muitas vezes poderia fazer a coisa certa se estivesse tentando ir atrás dos dados e encontrasse um ponteiro de procedimento. E os primeiros problemas que resolvi com minhas primeiras coisas em Utah foram o "desaparecimento de dados" usando apenas métodos e objetos. No final dos anos 60 (eu acho), Bob Balzer escreveu um artigo bastante bacana chamado "Dataless Programming", e logo depois John Reynolds escreveu um artigo igualmente bacana "Gedanken" (acho que em 1970) no qual ele mostrou que usando o lamda expressões da maneira correta permitiria que os dados fossem abstraídos por procedimentos.

As pessoas que gostaram de objetos como não-dados eram menores em número e incluíam eu, Carl Hewitt, Dave Reed e alguns outros - praticamente todo esse grupo era da comunidade do ARPA e estava envolvido de uma maneira ou de outra com o projeto da ARPAnet → Internet na qual a unidade básica de computação era um computador inteiro. Mas apenas para mostrar o quão teimosamente uma idéia pode se sustentar, durante os anos 70 e 80, muitas pessoas tentaram se dar bem com a "Chamada de Procedimento Remoto" em vez de pensar em objetos e mensagens. Sic transit gloria mundi.

Felicidades,

Alan Kay

A maioria, se não tudo, do que Alan Kay quis dizer com orientação a objetos está incorporada na linguagem Smalltalk.

Além disso, em http://en.wikipedia.org/wiki/Message_passing#Influences_on_other_programming_models :

Alan Kay argumentou que a passagem de mensagens é mais importante do que objetos no OOP, e que os objetos em si são frequentemente enfatizados demais. O modelo de programação de objetos distribuídos ao vivo se baseia nessa observação; ele usa o conceito de um fluxo de dados distribuído para caracterizar o comportamento de um sistema distribuído complexo em termos de padrões de mensagens, usando especificações de alto nível e estilo funcional.

A maioria, se não tudo, do que Alan Kay quis dizer com orientação a objetos está incorporada na linguagem Smalltalk.

"Nem sequer fizemos toda a ideia no PARC. Muitas das idéias de Carl Hewitt Actors que foram desencadeadas pelo Smalltalk original estavam mais no espírito de OOP do que nos Smalltalks subsequentes. Partes significativas de Erlang são mais como uma linguagem OOP real o Smalltalk atual e, certamente, as linguagens baseadas em C que foram pintadas com "OOP paint". "

Retirado do comentário de Alan Kay em:

http://computinged.wordpress.com/2010/09/11/moti-asks-objects-never-well-hardly-ever/

Um dos principais pontos que aprendi ao seguir os trabalhos de Alan Kay e outros, como Jim Coplien, é que a verdadeira programação orientada a "objetos" trata da modelagem de computadores e software em termos de modelos mentais HUMAN / USER, em vez de ser apenas uma ferramenta para PROGRAMADORES.

Pelo que entendi, a visão de Alan de OOP estava tornando o computador uma ferramenta que permite que um usuário humano faça o que quiser: todos os recursos do computador são diretamente expostos ao usuário final por meio de um modelo interativo intuitivo. Eu deveria poder visualizar e esculpir objetos e interações de tempo de execução DIRETAMENTE, não apenas através do código.

Aqui está um post sobre meus planos de tentar uma versão disso em JavaScript como prova de conceito: http://www.cemetech.net/forum/viewtopic.php?p=234494#234494

De uma perspectiva de desenvolvimento / programação de software, Jim Coplien fala sobre como o código pode e DEVE se parecer com o modelo mental do usuário. Ou seja, o código lê da mesma maneira que soaria por uma pessoa descrevendo seu comportamento. Isso é amplamente conseguido pensando em termos de OBJETOS, e não em CLASSES e TIPOS. O comportamento é descrito em termos dos papéis desempenhados por objetos, não como parte da definição de IDENTIDADE de um objeto. Você deve poder modelar interações em termos de objetos, identificados pelo ROLE que eles desempenham em uma interação. É assim que os modelos mentais humanos funcionam: garçom, cliente, caixa, conta de origem, conta de destino ... Esses são papéis, não tipos, e você deseja definir métodos para "qualquer objeto que esteja desempenhando esse papel no momento" ",