In 1985 Luca Cardelli and Peter Wegner, my advisor, published an ACM Computing Surveys paper called “On understanding types, data abstraction, and polymorphism”. Their work kicked off a flood of research on semantics and type theory for object-oriented programming, which continues to this day. Despite 25 years of research, there is still widespread confusion about the two forms of data abstraction, abstract data types and objects. This essay attempts to explain the differences and also why the differences matter.
Lire maintenant ?
gasche
Un article intéressant par quelqu’un reconnu dans la communauté de la "programmation orientée objet scientifique" (les gens ont d’autres discours que le charlatanisme à la "la poo c’est bien parce que le monde est fait d’objets"). Il explique que les "types abstraits de données" (ADT) et les objets sont fondamentalement différents, ont des forces et des faiblesses différentes et s’utilisent pour différents usages.
En deux mots, il considère que les deux permettent de définir un type de donnée et les opérations qui l’accompagnent. Dans le cas des ADT, la représentation du type est abstrait de l’extérieur mais commun à tous les éléments, donc les opérations définies à l’intérieur peuvent utiliser cette représentation, alors que dans le cas des objets il n’y a pas de représentation commune, et les opérations doivent être définies en fonction de l’interface externe. Les ADTs permettent donc de représenter des opérations multi-éléments efficaces (exploitant la représentation interne), alors que les objets permettent de mélanger des représentations différentes.
Cette définition n’apprend rien de l’idée mal définie que les gens appellent la "programmation orientée objet" : ces deux concepts sont utilisables facilement dans un langage fonctionnel (d’ailleurs le seul exemple d’objet donné est exactement fonctionnel), et on peut les voir comme deux "patterns" pour définir des opérations sur des données pour répondre à des besoins différents, et que l’on peut composer.
Point intéressant, il ne fait aucune mention de l’héritage, qu’il considère comme inessentiel pour la programmation orientée objet. Comme c’est la partie la plus compliquée (récursion ouverte) des langages dits "objets", il est intéressant de voir que des acteurs reconnus du monde objet la rejettent comme donnée conceptuelle de base. Cela me conforte dans l’idée qu’il vaut mieux des langages qui ne permettent pas directement l’héritage, et qui demandent de l’encoder explicitement quand elle est vraiment nécessaire (c’est ce qu’on fait quand on manipule des "récursions ouvertes" dans les langages fonctionnels). Non à l’héritage d’implémentation !