Alors qu'est-ce qu'Alan Kay entendait vraiment par «orienté objet»?

Alan Kay serait l'inventeur du terme "orienté objet". Et il est souvent cité comme ayant déclaré que ce que nous appelons aujourd'hui OO n'est pas ce qu'il voulait dire.

Par exemple, je viens de trouver ceci sur Google:

J'ai composé le terme 'orienté objet', et je peux vous dire que je n'avais pas à l'esprit le C ++

- Alan Kay, OOPSLA '97

Je me souviens vaguement avoir entendu quelque chose d' assez perspicace sur ce qu'il ne signifie pas . Quelque chose dans le sens du "message qui passe".

Savez-vous ce qu'il voulait dire? Pouvez-vous donner plus de détails sur ce qu'il voulait dire et en quoi cela diffère de l'OO commun d'aujourd'hui? S'il vous plaît partager quelques références si vous en avez.

Merci.

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

Date: mer. 23 juil. 2003 09:33:31 -0800 À: Stefan Ram [enlevé pour plus de protection de la vie privée] De: Alan Kay [enlevé pour plus de protection de la vie privée] Sujet: Re: Clarification de "orienté objet"

Salut Stefan -

Désolé pour le retard, mais j'étais en vacances.

À 18h27 +0200 le 17/07/03, Stefan Ram a écrit:

Cher Dr. Kay,

J'aimerais avoir un mot faisant autorité sur le terme "programmation orientée objet" pour ma page de tutoriel sur le sujet. Les deux seules sources que je considère comme faisant "autorité" sont l'Organisation internationale de normalisation, qui définit "orienté objet" dans "ISO / CEI 2382-15", et vous, car, comme on dit, vous avez inventé ce terme.

Je suis à peu près sûr de l'avoir fait.

Malheureusement, il est difficile de trouver une page Web ou une source avec votre définition ou description de ce terme. Il existe plusieurs rapports sur ce que vous auriez pu dire à cet égard (comme "héritage, polymorphisme et encapsulation"), mais ce ne sont pas des sources de première main. Je suis également conscient du fait que plus tard, vous avez mis davantage l'accent sur la "messagerie" - mais j'aimerais tout de même savoir "orienté objet".

Pour les enregistrements, ma page de tutoriel, ainsi que la distribution et la publication, pourriez-vous s'il vous plaît expliquer:

Où et quand le terme "orienté objet" a-t-il été utilisé en premier?

En Utah, quelque temps après le 66 novembre, lorsque, influencé par Sketchpad, Simula, le design de l’ARPAnet, du Burroughs B5000 et de ma formation en biologie et en mathématiques, j’ai pensé à une architecture de programmation. C'était probablement en 1967 quand quelqu'un m'a demandé ce que je faisais et j'ai dit: "C'est de la programmation orientée objet".

La conception originale de celui-ci avait les parties suivantes.

• Je pensais que les objets ressemblaient à des cellules biologiques et / ou à des ordinateurs individuels sur un réseau, uniquement capables de communiquer avec des messages (la messagerie est donc arrivée au tout début - il a fallu un certain temps pour voir comment faire de la messagerie dans un langage de programmation suffisamment efficace pour sois utile).

• Je voulais me débarrasser des données. Le B5000 a presque réussi à le faire via son architecture HW presque incroyable. J'ai réalisé que la métaphore de la cellule / de l'ordinateur complet supprimerait les données, et que "<-" ne serait qu'un autre jeton de message (il m'a fallu un bon bout de temps pour réfléchir à cela, car j'ai vraiment pensé à tous ces symboles comme des noms fonctions et procédures.

• Mes connaissances en mathématiques m'ont fait comprendre que chaque objet pouvait avoir plusieurs algèbres, des familles de celles-ci, qui seraient très utiles. Le terme "polymorphisme" a été imposé beaucoup plus tard (je pense par Peter Wegner) et il n'est pas tout à fait valable, car il provient vraiment de la nomenclature des fonctions, et je voulais bien plus que des fonctions. J'ai inventé le terme "généricité" pour traiter des comportements génériques sous une forme quasi algébrique.

• Je n'aimais pas la manière dont Simula I ou Simula 67 héritaient (même si je pensais que Nygaard et Dahl étaient simplement des penseurs et des concepteurs formidables). J'ai donc décidé de laisser l'héritage en tant que fonctionnalité intégrée jusqu'à ce que je le comprenne mieux.

Mes expériences originales avec cette architecture ont été réalisées à l'aide d'un modèle que j'ai adapté de "Generalization of Algol" de Wijngaarten et Wirth et de Euler de Wirth. Tous deux ressemblaient plutôt à LISP mais avec une syntaxe lisible plus conventionnelle. À l'époque, je ne comprenais pas l'idée du métalangage tangible dans LISP, mais je me rapprochais des idées sur les langages extensibles puisées dans différentes sources, y compris IMP.

La deuxième phase consistait à finalement comprendre le LISP, puis à utiliser cette compréhension pour créer des sous-structures beaucoup plus agréables, plus petites, plus puissantes et plus tardives. La thèse de Dave Fisher a été réalisée dans le style "McCarthy" et ses idées sur les structures de contrôle extensibles ont été très utiles. Le planificateur de Carl Hewitt (qui n’a jamais obtenu la reconnaissance qu’il mérite, en raison de la qualité et de la rapidité avec lesquelles il a pu anticiper sur Prolog) a été une autre grande influence à cette époque.

Le Smalltalk original de Xerox PARC est issu de ce qui précède. Les derniers Smalltalk se sont plaints à la fin du chapitre d'Histoire: ils ont rétrogradé vers Simula et n'ont pas remplacé les mécanismes d'extension par des mécanismes plus sûrs et aussi utiles.

Qu'est-ce que "programmation orientée objet" signifie pour vous? (Aucune introduction de type tutoriel n'est nécessaire, juste une courte explication [du type "programmation avec héritage, polymorphisme et encapsulation"] en termes d'autres concepts pour un lecteur familier, si possible. En outre, il n'est pas nécessaire d'expliquer "objet" ", parce que j'ai déjà des sources avec votre explication de" objet "de" Early History of Smalltalk ".)

(Je ne suis pas contre les types, mais je ne connais aucun système de type qui ne soit pas une douleur complète, donc j'aime toujours la dactylographie dynamique.)

La POO pour moi ne signifie que la messagerie, la rétention et la protection locales et le masquage du processus d'état, et la liaison tardive extrême de toutes choses. Cela peut être fait en Smalltalk et en LISP. Il existe peut-être d'autres systèmes dans lesquels cela est possible, mais je ne les connais pas.

[Aussi] L'une des choses que j'aurais dû mentionner est qu'il y avait deux voies principales qui ont été catalysées par Simula. La première (juste par accident) était la voie bio / net que je prenais. L'autre, qui est venu un peu plus tard comme objet d'étude, était constitué de types de données abstraits, ce qui a entraîné beaucoup plus de jeu.

Si nous regardons l’ensemble de l’histoire, nous voyons que les proto-OOP ont commencé avec ADT, qu’il y avait une petite fourchette vers ce que j’appelais des "objets" - ce qui a conduit à Smalltalk, etc., - mais après la petite fourche, le L'établissement CS a à peu près fait ADT et voulait s'en tenir au paradigme de la procédure de données. Historiquement, cela vaut la peine d’examiner le système de fichiers USAF Burroughs 220 (que j’ai décrit dans l’histoire de Smalltalk), les travaux antérieurs de Doug Ross au MIT (AED et antérieurs) dans lesquels il préconisait l’ajout de pointeurs de procédure dans des structures de données, Sketchpad (qui polymorphisme complet - où, par exemple, le même décalage dans sa structure de données signifiait "affichage" et qu'il y aurait un pointeur sur la routine appropriée pour le type d'objet représenté par la structure, etc., et le Burroughs B5000, dont les tables de référence de programme étaient de vrais "gros objets" et contenaient des pointeurs vers les "données" et les "procédures", mais pouvaient souvent faire ce qui était juste si elles essayaient de rechercher des données et de trouver un pointeur de procédure. Et les tous premiers problèmes que j'ai résolus avec mes débuts dans l'Utah étaient la "disparition de données" en utilisant uniquement des méthodes et des objets. À la fin des années 60 (je pense), Bob Balzer a écrit un article plutôt intéressant appelé "Dataless Programming" (Programmation sans données) et peu de temps après, John Reynolds a rédigé un article tout aussi intéressant "Gedanken" (en 1970, je pense) dans lequel il montrait que les expressions de la bonne manière permettrait aux données d’être extraites par des procédures. mais pourrait souvent faire la bonne chose si elle essayait de rechercher des données et de trouver un pointeur de procédure. Et les tous premiers problèmes que j'ai résolus avec mes débuts dans l'Utah étaient la "disparition de données" en utilisant uniquement des méthodes et des objets. À la fin des années 60 (je pense), Bob Balzer a écrit un article plutôt intéressant appelé "Dataless Programming" (Programmation sans données) et peu de temps après, John Reynolds a rédigé un article tout aussi intéressant "Gedanken" (en 1970, je pense) dans lequel il montrait que les expressions de la bonne manière permettrait aux données d’être extraites par des procédures. mais pourrait souvent faire la bonne chose si elle essayait de rechercher des données et de trouver un pointeur de procédure. Et les tous premiers problèmes que j'ai résolus avec mes débuts dans l'Utah étaient la "disparition de données" en utilisant uniquement des méthodes et des objets. À la fin des années 60 (je pense), Bob Balzer a écrit un article plutôt intéressant appelé "Dataless Programming" (Programmation sans données) et peu de temps après, John Reynolds a rédigé un article tout aussi intéressant "Gedanken" (en 1970, je pense) dans lequel il montrait que les expressions de la bonne manière permettrait aux données d’être extraites par des procédures.

Les personnes qui aimaient les objets en tant que non-données étaient moins nombreuses et comprenaient moi-même, Carl Hewitt, Dave Reed et quelques autres - à peu près tout ce groupe appartenait à la communauté ARPA et participait d'une manière ou d'une autre à la conception d'ARPAnet → Internet dans laquelle l'unité de calcul de base était un ordinateur complet. Mais pour montrer à quel point une idée peut rester obstinément accrochée, tout au long des années soixante-dix et quatre-vingt, de nombreuses personnes ont essayé de se débrouiller avec "Appel de procédure à distance" au lieu de penser à des objets et à des messages. Sic transit gloria mundi.

À votre santé,

Alan Kay

La plupart, sinon la totalité, de ce que Alan Kay entend par orientation objet est incarné dans le langage Smalltalk.

Voir également http://en.wikipedia.org/wiki/Message_passing#Influences_on_other_programming_models :

Alan Kay a fait valoir que la transmission de messages est plus importante que les objets en POO et que les objets eux-mêmes sont souvent surestimés. Le modèle de programmation des objets distribués en direct s'appuie sur cette observation; il utilise le concept de flux de données distribué pour caractériser le comportement d'un système distribué complexe en termes de modèles de messages, en utilisant des spécifications de haut niveau, de style fonctionnel.

La plupart, sinon la totalité, de ce que Alan Kay entend par orientation objet est incarné dans le langage Smalltalk.

"Nous n'avions même pas fait toute cette idée au PARC. Beaucoup d'idées d'acteurs de Carl Hewitt qui ont été suscitées par le Smalltalk original étaient plus dans l'esprit de la POO que les Smalltalks ultérieurs. Les parties significatives d'Erlang ressemblent davantage à un vrai langage de POO. Le Smalltalk actuel, et certainement les langages basés sur le C qui ont été peints avec «peinture OOP». "

Tiré du commentaire d'Alan Kay à:

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

Un des points importants que j’ai retenu en suivant les travaux d’Alan Kay et d’autres, tels que Jim Coplien, est que la véritable programmation orientée "objet" concerne la modélisation des ordinateurs et des logiciels en termes de modèles mentaux HUMAN / USER, juste un outil pour les programmeurs.

Si je comprends bien, la vision d'AOP d'Alan était de faire de l'ordinateur un outil qui permet à un utilisateur humain de créer ce qu'il veut: toutes les fonctionnalités de l'ordinateur sont directement exposées pour l'utilisateur final au moyen d'un modèle interactif intuitif. Je devrais être capable de visualiser et de sculpter les objets et les interactions d'exécution DIRECTEMENT, pas seulement à travers le code.

Voici un article sur mon projet d'essayer d'utiliser une version de JavaScript comme une preuve de concept: http://www.cemetech.net/forum/viewtopic.php?p=234494#234494

Dans une perspective de développement / programmation de logiciels, Jim Coplien explique comment le code peut et DEVRAIT ressembler au modèle mental de celui-ci. Autrement dit, le code se lit pratiquement de la même manière que le ferait une personne décrivant son comportement. Ceci est en grande partie accompli en pensant en termes d’OBJETS, plutôt qu’en termes de CLASSES et de TYPES. Le comportement est décrit en termes de ROLES joués par des objets, pas dans le cadre de la définition de l'identité d'un objet. Vous devriez être capable de modéliser les interactions en termes d'objets, qui sont identifiés par le rôle qu'ils jouent dans une interaction. Voici comment fonctionnent les modèles mentaux humains: serveur, client, caissier, compte source, compte de destination, ... Ce sont des ROLES, pas des TYPES, et vous souhaitez pouvoir définir des méthodes pour "tout objet jouant ce rôle à ce moment" ",