Entonces, ¿qué * Alan * realmente quiso decir con el término "orientado a objetos"?

Según se informa, Alan Kay es el inventor del término "orientado a objetos". Y a menudo se lo cita diciendo que lo que llamamos OO hoy no es lo que quiso decir.

Por ejemplo, acabo de encontrar esto en Google:

Creé el término 'orientado a objetos', y puedo decirte que no tenía en mente C ++

- Alan Kay, OOPSLA '97

Recuerdo vagamente haber escuchado algo bastante perspicaz sobre lo que quería decir. Algo en la línea de "pasar mensajes".

¿Sabes a qué se refería? ¿Puede completar más detalles de lo que quiso decir y cómo difiere del OO común de hoy? Comparta algunas referencias si tiene alguna.

Gracias.

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

Fecha: miércoles 23 de julio de 2003 09:33:31 -0800 Para: Stefan Ram [eliminado por privacidad] De: Alan Kay [eliminado por privacidad] Asunto: Re: Aclaración de "orientado a objetos"

Hola stefan

Perdón por la demora pero estaba de vacaciones.

A las 6:27 PM +0200 17/07/03, Stefan Ram escribió:

Estimado Dr. Kay,

Me gustaría tener alguna palabra autorizada sobre el término "programación orientada a objetos" para mi página de tutorial sobre el tema. Las únicas dos fuentes que considero "autorizadas" son la Organización Internacional de Normalización, que define "orientado a objetos" en "ISO / IEC 2382-15", y usted, porque, como dicen, ha acuñado ese término.

Estoy bastante seguro de que lo hice.

Desafortunadamente, es difícil encontrar una página web o fuente con su definición o descripción de ese término. Hay varios informes sobre lo que podría haber dicho a este respecto (como "herencia, polimorfismo y encapsulación"), pero estas no son fuentes de primera mano. También soy consciente de que más adelante se pone más énfasis en la "mensajería", pero aún me gustaría saber sobre "orientado a objetos".

Para los registros, mi página de tutoría y más distribución y publicación, ¿podría explicar:

¿Cuándo y dónde se usó primero el término "orientado a objetos"?

En Utah, en algún momento después del 66 de noviembre, cuando, influenciado por Sketchpad, Simula, el diseño de ARPAnet, el Burroughs B5000 y mi experiencia en Biología y Matemáticas, pensé en una arquitectura para la programación. Probablemente fue en 1967 cuando alguien me preguntó qué estaba haciendo y yo dije: "Es una programación orientada a objetos".

La concepción original de la misma tenía las siguientes partes.

• Pensé en los objetos como células biológicas y / o computadoras individuales en una red, solo capaces de comunicarse con los mensajes (por lo que los mensajes llegaron al principio, tomó un tiempo ver cómo hacer mensajes en un lenguaje de programación lo suficientemente eficiente como para sé útil).

• Quería deshacerme de los datos. El B5000 casi hizo esto a través de su arquitectura HW casi increíble. Me di cuenta de que la metáfora de la célula / computadora completa eliminaría los datos, y que "<-" sería solo otra señal de mensaje (me tomó bastante tiempo pensar esto porque realmente pensé en todos estos símbolos como nombres para funciones y procedimientos.

• Mi formación matemática me hizo darme cuenta de que cada objeto podría tener varias álgebras asociadas, y podría haber familias de estos, y que estos serían muy, muy útiles. El término "polimorfismo" se impuso mucho más tarde (creo que Peter Wegner) y no es del todo válido, ya que realmente proviene de la nomenclatura de funciones, y quería un poco más que funciones. Creé un término "genérico" para tratar comportamientos genéricos en una forma cuasi algebraica.

• No me gustó la forma en que Simula I o Simula 67 heredaron (aunque pensé que Nygaard y Dahl eran simplemente pensadores y diseñadores tremendos). Así que decidí dejar de lado la herencia como una característica incorporada hasta que lo entendí mejor.

Mis experimentos originales con esta arquitectura se realizaron utilizando un modelo que adapté de la "Generalización de Algol" de Van Wijngaarten y Wirth y Euler de Wirth. Ambos eran bastante parecidos a LISP pero con una sintaxis legible más convencional. Entonces no entendí la idea monstruosa LISP del metalenguaje tangible, pero me acerqué un poco a las ideas sobre lenguajes extensibles extraídos de varias fuentes, incluido el IMP de Irons.

La segunda fase de esto fue finalmente comprender LISP y luego usar esta comprensión para crear estructuras inferiores mucho más bonitas, más pequeñas, más potentes y más tardías. La tesis de Dave Fisher se realizó al estilo "McCarthy" y sus ideas sobre las estructuras de control extensibles fueron muy útiles. Otra gran influencia en este momento fue el PLANIFICADOR de Carl Hewitt (que nunca obtuvo el reconocimiento que merece, dado lo bien y lo temprano que pudo anticipar a Prolog).

El Smalltalk original en Xerox PARC salió de lo anterior. Los Smalltalk posteriores se quejaron al final del capítulo de Historia: retrocedieron hacia Simula y no reemplazaron los mecanismos de extensión por otros más seguros que eran tan útiles.

¿Qué significa para usted "programación orientada a objetos"? (No se necesita una introducción similar a un tutorial, solo una breve explicación [como "programación con herencia, polimorfismo y encapsulación"] en términos de otros conceptos para un lector familiarizado con ellos, si es posible. Además, no es necesario explicar el "objeto" ", porque ya tengo fuentes con su explicación de" objeto "de" Early History of Smalltalk ".)

(No estoy en contra de los tipos, pero no conozco ningún sistema de tipos que no sea una molestia completa, por lo que todavía me gusta la escritura dinámica).

OOP para mí significa solo mensajes, retención y protección local y ocultación del proceso estatal, y un enlace tardío extremo de todas las cosas. Se puede hacer en Smalltalk y en LISP. Posiblemente hay otros sistemas en los que esto es posible, pero no estoy al tanto de ellos.

[Además,] Una de las cosas que debería haber mencionado es que había dos caminos principales que fueron catalizados por Simula. La primera (solo por accidente) fue la ruta bio / neta sin procedimiento de datos que tomé. El otro, que llegó un poco más tarde como objeto de estudio, fue los tipos de datos abstractos, y esto tuvo mucho más juego.

Si miramos toda la historia, vemos que las cosas de proto-OOP comenzaron con ADT, tenían un pequeño tenedor hacia lo que llamé "objetos", que condujeron a Smalltalk, etc., pero después del pequeño tenedor, el El establecimiento de CS prácticamente hizo ADT y quería seguir con el paradigma del procedimiento de datos. Históricamente, vale la pena mirar el sistema de archivos USAF Burroughs 220 (que describí en la historia de Smalltalk), el trabajo inicial de Doug Ross en el MIT (AED y anteriores) en el que abogó por incorporar punteros de procedimiento en estructuras de datos, Sketchpad (que tenía polimorfismo completo, donde, por ejemplo, el mismo desplazamiento en su estructura de datos significaba "visualización" y habría un puntero a la rutina apropiada para el tipo de objeto que esa estructura representaba, etc., y el Burroughs B5000, cuyas tablas de referencia de programas eran verdaderos "objetos grandes" y contenían punteros tanto a "datos" como a "procedimientos", pero a menudo podían hacer lo correcto si intentaban buscar datos y encontraban un puntero de procedimiento. Y los primeros problemas que resolví con mis primeras cosas en Utah fueron la "desaparición de datos" utilizando solo métodos y objetos. A finales de los años 60 (creo), Bob Balzer escribió un artículo bastante ingenioso llamado "Programación sin datos", y poco después John Reynolds escribió un artículo igualmente ingenioso "Gedanken" (en 1970, creo) en el que demostró que usando el lamda las expresiones de la manera correcta permitirían que los datos se abstraigan mediante procedimientos. pero a menudo podía hacer lo correcto si intentaba buscar datos y encontraba un puntero de procedimiento. Y los primeros problemas que resolví con mis primeras cosas en Utah fueron la "desaparición de datos" utilizando solo métodos y objetos. A finales de los años 60 (creo), Bob Balzer escribió un artículo bastante ingenioso llamado "Programación sin datos", y poco después John Reynolds escribió un artículo igualmente ingenioso "Gedanken" (en 1970, creo) en el que demostró que usando el lamda las expresiones de la manera correcta permitirían que los datos se abstraigan mediante procedimientos. pero a menudo podía hacer lo correcto si intentaba buscar datos y encontraba un puntero de procedimiento. Y los primeros problemas que resolví con mis primeras cosas en Utah fueron la "desaparición de datos" utilizando solo métodos y objetos. A finales de los años 60 (creo), Bob Balzer escribió un artículo bastante ingenioso llamado "Programación sin datos", y poco después John Reynolds escribió un artículo igualmente ingenioso "Gedanken" (en 1970, creo) en el que demostró que usando el lamda las expresiones de la manera correcta permitirían que los datos se abstraigan mediante procedimientos.

Las personas a las que les gustaban los objetos como no datos eran más pequeñas en número, e incluía a mí, Carl Hewitt, Dave Reed y algunos otros; casi todo este grupo era de la comunidad ARPA y estaban involucrados de una manera u otra con el diseño de ARPAnet → Internet en el que la unidad básica de computación era una computadora completa. Pero solo para mostrar cuán tercamente puede durar una idea, a lo largo de los años setenta y ochenta, hubo muchas personas que intentaron sobrevivir con "Llamada a procedimiento remoto" en lugar de pensar en objetos y mensajes. Sic transit gloria mundi.

Salud,

Alan Kay

La mayoría, si no todo, de lo que Alan Kay quiso decir con orientación a objetos está incorporado en el lenguaje Smalltalk.

Además, de http://en.wikipedia.org/wiki/Message_passing#Influences_on_other_programming_models :

Alan Kay ha argumentado que la transmisión de mensajes es más importante que los objetos en OOP, y que los objetos mismos a menudo se sobre enfatizan. El modelo de programación de objetos distribuidos en vivo se basa en esta observación; utiliza el concepto de flujo de datos distribuidos para caracterizar el comportamiento de un sistema distribuido complejo en términos de patrones de mensajes, utilizando especificaciones de alto nivel y estilo funcional.

La mayoría, si no todo, de lo que Alan Kay quiso decir con orientación a objetos está incorporado en el lenguaje Smalltalk.

"Ni siquiera hicimos toda la idea en PARC. Muchas de las ideas de los actores de Carl Hewitt que surgieron de Smalltalk original estaban más en el espíritu de OOP que los Smalltalks posteriores. Partes significativas de Erlang son más como un verdadero lenguaje de OOP el Smalltalk actual, y ciertamente los lenguajes basados ​​en C que han sido pintados con "OOP paint".

Tomado del comentario de Alan Kay en:

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

Uno de los puntos principales que he recogido al seguir los trabajos de Alan Kay y otros como Jim Coplien es que la verdadera programación orientada a "objetos" se trata de modelar computadoras y software en términos de modelos mentales HUMANOS / USUARIOS, en lugar de ser solo una herramienta para PROGRAMADORES.

Según tengo entendido, la visión de Alan de OOP fue hacer de la computadora una herramienta que permita a un usuario humano hacer lo que quiera: las capacidades completas de la computadora están directamente expuestas al usuario final a través de un modelo interactivo intuitivo. Debería poder ver y esculpir objetos e interacciones en tiempo de ejecución DIRECTAMENTE, no solo a través del código.

Aquí hay una publicación sobre mis planes para intentar una versión de esto en JavaScript como prueba de concepto: http://www.cemetech.net/forum/viewtopic.php?p=234494#234494

Desde una perspectiva de desarrollo / programación de software, Jim Coplien habla sobre cómo el código puede y DEBE parecerse al modelo mental del usuario. Es decir, el código se lee de la misma manera que lo haría una persona que describe su comportamiento. Esto se logra en gran medida al pensar en términos de OBJETOS, en lugar de en términos de CLASES y TIPOS. El comportamiento se describe en términos de los ROLES que juegan los objetos, no como parte de la definición de IDENTIDAD de un objeto. Debería poder modelar interacciones en términos de objetos, que se identifican por el PAPEL que desempeñan en una interacción. Así es como funcionan los modelos mentales humanos: camarero, cliente, cajero, cuenta de origen, cuenta de destino, ... Estos son ROLES, no TIPOS, y desea poder definir métodos para "cualquier objeto que esté desempeñando este papel en ese momento". ",