Alors, qu'est-ce que * Alan Kay voulait vraiment dire par le terme "orienté objet"?
Selon certaines sources, Alan Kay est l'inventeur du terme "orienté objet". Et il est souvent cité comme ayant dit que ce que nous appelons OO aujourd'hui n'est pas ce qu'il voulait dire.
Par exemple, je viens de trouver ceci sur Google:
J'ai inventé le terme "orienté objet", et je peux vous dire que je n'avais pas le C++ en tête
- Alan Kay, OOPSLA '97
Je me souviens vaguement d'avoir entendu quelque chose d'assez perspicace sur ce qu'il faisait voulait dire. Quelque chose dans le sens d'un "message qui passe".
Tu sais ce qu'il voulait dire? Pouvez-vous donner plus de détails sur ce qu'il voulait dire et en quoi il diffère des OO courants d'aujourd'hui? Veuillez 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 [supprimé pour des raisons de confidentialité] De: Alan Kay [supprimé pour des raisons de confidentialité] Objet: Objet: Clarification de "orienté objet"
Salut Stefan -
Désolé pour le retard mais j'étais en vacances.
À 6 h 27 PM +0200 17/07/03, Stefan Ram a écrit:
Cher Dr Kay,
Je voudrais 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ée objet" dans "ISO/CEI 2382-15", et vous, parce que, comme on dit, vous avez inventé ce terme.
Je suis presque 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 que plus tard, vous mettez davantage l'accent sur la "messagerie" - mais j'aimerais tout de même en savoir plus sur "orienté objet".
Pour les enregistrements, ma page de tutoriel, et la distribution et la publication supplémentaires pourriez-vous expliquer:
Quand et où le terme "orienté objet" a-t-il été utilisé en premier?
À Utah quelque temps après le 66 novembre, lorsque, influencé par Sketchpad, Simula, la conception de l'ARPAnet, le Burroughs B5000 et ma formation en biologie et mathématiques, j'ai pensé à une architecture pour la programmation. C'était probablement en 1967 quand quelqu'un m'a demandé ce que je faisais et j'ai dit: "C'est une programmation orientée objet".
Sa conception originale comportait les parties suivantes.
Je pensais que les objets étaient comme des cellules biologiques et/ou des ordinateurs individuels sur un réseau, seulement capables de communiquer avec des messages (donc la messagerie est arrivée au tout début - il a fallu un certain temps pour voir comment faire la messagerie dans un langage de programmation suffisamment efficacement pour sois utile).
Je voulais me débarrasser des données. Le B5000 l'a presque fait via son architecture HW presque incroyable. J'ai réalisé que la métaphore cellule/ordinateur entier se débarrasserait des données, et que "<-" ne serait qu'un autre jeton de message (il m'a fallu un certain temps pour y réfléchir parce que je pensais vraiment à tous ces symboles comme des noms pour fonctions et procédures.
Mes connaissances en mathématiques m'ont fait réaliser que chaque objet pouvait avoir plusieurs algèbres associées, et qu'il pouvait y avoir des familles de celles-ci, et que celles-ci seraient très 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 vient vraiment de la nomenclature des fonctions, et je voulais un peu plus que des fonctions. J'ai inventé un terme "généricité" pour traiter des comportements génériques sous une forme quasi-algébrique.
Je n'aimais pas la façon dont Simula I ou Simula 67 faisait l'héritage (même si je pensais que Nygaard et Dahl n'étaient que de formidables penseurs et concepteurs). 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é faites en utilisant un modèle que j'ai adapté de "Generalization of ALGOL" de van Wijngaarten et Wirth et Euler de Wirth. Les deux étaient plutôt de type LISP mais avec une syntaxe lisible plus conventionnelle. Je ne comprenais pas l'idée monstre LISP du métalangage tangible à l'époque, mais je me suis rapproché des idées sur les langages extensibles puisés dans diverses sources, dont l'IMP d'Irons.
La deuxième phase consistait à comprendre enfin LISP, puis à utiliser cette compréhension pour créer des sous-structures beaucoup plus belles et 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. Une autre grande influence à cette époque était le PLANIFICATEUR de Carl Hewitt (qui n'a jamais obtenu la reconnaissance qu'il mérite, étant donné à quel point et à quel point il a pu anticiper Prolog).
Le Smalltalk original de Xerox PARC est né de ce qui précède. Les Smalltalk suivants sont critiqués à la fin du chapitre Histoire: ils se sont rétrogradés vers Simula et n'ont pas remplacé les mécanismes d'extension par des mécanismes plus sûrs qui étaient presque aussi utiles.
Que signifie pour vous la "programmation orientée objet"? (Aucune introduction semblable à un didacticiel n'est nécessaire, juste une courte explication [comme "programmation avec héritage, polymorphisme et encapsulation"] en termes d'autres concepts pour un lecteur qui les connaît, si possible. De plus, il n'est pas nécessaire d'expliquer "object ", car 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 frappe dynamique.)
Pour moi, la POO signifie uniquement la messagerie, la conservation et la protection locales et la dissimulation du processus étatique, et la liaison tardive extrême de toutes choses. Cela peut être fait dans Smalltalk et dans LISP. Il existe peut-être d'autres systèmes dans lesquels cela est possible, mais je n'en ai pas connaissance.
[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) a été la voie non-bio-net-procédure que j'ai empruntée. L'autre, qui est venu un peu plus tard en tant qu'objet d'étude, était les types de données abstraits, et cela a joué beaucoup plus.
Si nous regardons toute l'histoire, nous voyons que les choses proto-OOP ont commencé avec ADT, avaient une petite fourchette vers ce que j'appelais des "objets" - qui a conduit à Smalltalk, etc., - mais après la petite fourchette, le La création de CS a fait à peu près ADT et voulait s'en tenir au paradigme de la procédure de données. Historiquement, il vaut la peine de regarder le système de fichiers USAF Burroughs 220 (que j'ai décrit dans l'histoire de Smalltalk), les premiers travaux de Doug Ross à MIT (AED et plus tôt) dans lequel il préconisait la procédure d'intégration pointeurs dans les structures de données, Sketchpad (qui avait un polymorphisme complet - où, par exemple, le même décalage dans sa structure de données signifiait "affichage" et il y aurait un pointeur vers la routine appropriée pour le type d'objet que la structure représentait, etc., et le Burroughs B5000, dont les tables de référence de programme étaient de véritables "gros objets" et contenaient des pointeurs vers les "données" et les "procédures", mais pouvaient souvent faire la bonne chose s'il essayait d'aller après les données et de trouver un pointeur de procédure. Et le tout premier les problèmes que j'ai résolus avec mes premiers trucs de l'Utah étaient la "disparition des 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 assez astucieux intitulé "Programmation sans données", et peu de temps après, John Reynolds a écrit un papier tout aussi astucieux "Ged anken "(en 1970, je pense), dans lequel il a montré que l'utilisation des expressions lamda de la bonne façon permettrait d'abstraire les données par des procédures.
Les personnes qui aimaient les objets en tant que non-données étaient plus petites et comprenaient moi-même, Carl Hewitt, Dave Reed et quelques autres - à peu près tout ce groupe était de la ARPA communauté et ont été impliqués d'une manière ou d'une autre dans la conception d'ARPAnet → Internet dans lequel l'unité de calcul de base était un ordinateur entier. Mais juste pour montrer à quel point une idée peut persister, tout au long des années 70 et 80, il y avait beaucoup de gens qui essayé de se débrouiller avec "Remote Procedure Call" au lieu de penser aux objets et aux messages. Sic transit gloria mundi.
À votre santé,
Alan Kay
La plupart sinon la totalité de ce qu'Alan Kay entendait par l'orientation objet est incarnée dans le langage Smalltalk.
Aussi, depuis http://en.wikipedia.org/wiki/Message_passing#Influences_on_other_programming_models :
Alan Kay a soutenu que la transmission de messages est plus importante que les objets dans la POO, et que les objets eux-mêmes sont souvent surestimés. Le modèle de programmation d'objets distribués en direct s'appuie sur cette observation; il utilise le concept d'un flux de données distribué pour caractériser le comportement d'un système distribué complexe en termes de modèles de message, en utilisant des spécifications de style fonctionnel de haut niveau.
La plupart sinon la totalité de ce qu'Alan Kay entendait par orientation objet est incarnée dans le langage Smalltalk.
"Nous n'avons même pas fait toute l'idée au PARC. Beaucoup d'idées d'acteurs de Carl Hewitt qui ont été déclenchées par le Smalltalk original étaient plus dans l'esprit de OOP que les Smalltalks suivantes. Pièces importantes d'Erlang ressemble plus à un vrai OOP langage le Smalltalk actuel, et certainement les langages basés sur C qui ont été peints avec "OOP Paint". "
Extrait du commentaire d'Alan Kay à:
http://computinged.wordpress.com/2010/09/11/moti-asks-objects-never-well-hardly-ever/
L'un des principaux points que j'ai retenus 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 HUMAINS/UTILISATEURS, plutôt que d'être juste un outil pour les PROGRAMMATEURS.
Si je comprends bien, la vision d'Alan de OOP faisait de l'ordinateur un outil qui permet à un utilisateur humain de faire ce qu'il veut: toutes les capacités de l'ordinateur sont directement exposées à l'utilisateur final via un modèle interactif intuitif. Je devrais être capable de visualiser et de sculpter des objets d'exécution et des interactions DIRECTEMENT, pas seulement à travers du code.
Voici un article sur mes plans pour tenter une version de ceci en JavaScript comme preuve de concept: http://www.cemetech.net/forum/viewtopic.php?p=234494#234494
Du point de vue du développement/programmation de logiciels, Jim Coplien explique comment le code peut et DEVRAIT ressembler au modèle mental des utilisateurs. Autrement dit, le code se lit à peu près de la même manière que cela pourrait paraître par 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 TYPES. Le comportement est décrit en fonction des RÔLES joués par les objets, et non dans le cadre de la définition de l'IDENTITÉ d'un objet. Vous devriez être en mesure 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 RÔLES, pas des TYPES, et vous voulez pouvoir définir des méthodes pour "quel que soit l'objet qui joue ce rôle à l'époque ", car ce comportement fait partie d'une interaction système entre de nombreux objets changeants, plutôt qu'une partie de la définition d'un TYPE.