Au cours du premier semestre, nous avons découvert les concepts de la programmation orientée objet tels que l'encapsulation, le masquage des données, la modularité, l'héritage, etc. via Java et UML. (Java est mon premier langage de programmation)
Aucun de ceux-ci ne sont des concepts de POO. Ils existent tous en dehors de OO, indépendamment de OO et beaucoup ont même été inventés avant OO.
Donc, si vous pensez que c'est ça le but de OO, alors votre conclusion est juste: vous pouvez faire tout cela dans des langages procéduraux, car ils n'ont rien à voir avec OO .
Par exemple, l’un des principaux articles sur la modularité concerne les critères à utiliser pour la décomposition de systèmes en modules . Il n'y a aucune mention de OO là-dedans. (Il a été écrit en 1972, alors que OO était encore un créneau obscur, alors qu’il avait déjà plus de dix ans.)
Bien que l’ abstraction de données soit importante pour l’OA, c’est davantage une conséquence de la principale caractéristique de OO (messagerie) qu’elle est déterminante. En outre, il est très important de se rappeler qu’il existe différents types d’abstraction de données. Les deux types d'abstraction de données les plus couramment utilisés aujourd'hui (si nous ignorons "aucune abstraction", qui est probablement encore plus utilisé que les deux autres combinés), sont les types de données abstraits et les objets . Donc, juste en disant « Hiding information », « Encapsulation » et « Data Abstraction », vous avez rien dit sur OO, puisque OO est seulement une forme d'abstraction de données, et les deux sont en fait fondamentalement différentes:
- Avec les types de données abstraits, le mécanisme d’abstraction est le système de types ; c'est le système de types qui cache l'implémentation. (Le système de types ne doit pas nécessairement être statique.) Avec Objects, l'implémentation est cachée derrière une interface procédurale , qui ne nécessite pas de types. (Par exemple, il peut être implémenté avec des fermetures, comme dans ECMAScript.)
- Avec les types de données abstraits, les instances de différents types de TDA sont encapsulées les unes par rapport aux autres, mais les instances du même TDA peuvent inspecter et accéder à la représentation et à l'implémentation privée de l'autre. Les objets sont toujours encapsulés de tout . Seul l'objet lui-même peut inspecter sa propre représentation et accéder à sa propre implémentation privée. Aucun autre objet , pas même d'autres objets du même type, d'autres instances de la même classe, d'autres objets ayant le même prototype, des clones de l'objet ou quoi que ce soit ne peut le faire. Aucun .
Soit dit en passant, cela signifie qu'en Java, les classes ne sont pas orientées objet. Deux instances de la même classe peuvent accéder à la représentation et à l'implémentation privée de l'autre. Par conséquent, les instances de classes ne sont pas des objets, elles sont en fait des instances ADT. Java interface
s, cependant, ne fournir abstraction de données orientée objet. Donc, en d'autres termes: seules les instances d'interfaces sont des objets en Java, les instances de classes ne le sont pas.
Fondamentalement, pour les types, vous ne pouvez utiliser que des interfaces. Cela signifie que les types de paramètres de méthodes et de constructeurs, les types de méthodes retournés, les types de champs d'instance, les champs statiques et les champs locaux, l'argument d'un instanceof
opérateur ou d'un opérateur de conversion et les arguments de type d'un constructeur de type générique doivent toujours être des interfaces. Une classe ne peut être utilisée que directement après l' new
opérateur, nulle part ailleurs.
Par exemple, pour la modularité, nous pouvons simplement diviser le programme en plusieurs petits programmes qui exécutent des tâches bien définies dont le code est contenu dans des fichiers séparés. Ces programmes interagiraient les uns avec les autres grâce à leurs entrées et sorties bien définies. Les fichiers peuvent être protégés (cryptés?) Pour réaliser l’encapsulation. Pour la réutilisation du code, nous pouvons simplement appeler ces fichiers quand ils sont nécessaires dans de nouveaux programmes. Cela ne reflète-t-il pas tout ce qu'est la POO ou manque-t-il quelque chose de très évident?
Ce que vous décrivez est OO.
C'est en effet une bonne façon de penser à OO. En fait, c'est à peu près exactement ce que les inventeurs originaux d'OO avaient en tête. (Alan Kay est allé un peu plus loin: il a envisagé de nombreux ordinateurs se transmettant des messages via le réseau.) Ce que vous appelez "programme" est généralement appelé "objet" et au lieu de "appel", nous disons habituellement "envoyer un message" ".
L'orientation des objets est entièrement centrée sur la messagerie (également appelée répartition dynamique ). Le terme "orienté objet" a été inventé par Alan Kay, concepteur principal de Smalltalk, et il le définit ainsi :
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.
Décomposons cela:
- messagerie ("envoi de méthode virtuelle", si vous n'êtes pas familier avec Smalltalk)
- processus d'état devrait être
- conservé localement
- protégé
- caché
- liaison tardive extrême de toutes choses
En ce qui concerne l'implémentation, la messagerie est un appel de procédure à liaison tardive, et si les appels de procédure sont à liaison tardive, vous ne pouvez pas savoir au moment de la conception comment vous allez appeler, vous ne pouvez donc pas émettre d'hypothèses sur la représentation concrète de l'état. Donc, en réalité, il s’agit de messagerie, la liaison tardive est une implémentation de la messagerie et l’encapsulation en est la conséquence.
Il a ensuite précisé que " la grande idée est la" messagerie " " et regrette de l'avoir appelée "orientée objet" au lieu de "orientée message", car le terme "orienté objet" met l'accent sur l'élément sans importance (objets ) et distrait de ce qui est vraiment important (messagerie):
Juste un rappel gentil que j’ai pris quelques efforts lors du dernier OOPSLA pour essayer de rappeler à tout le monde que Smalltalk n’est PAS seulement sa syntaxe ou sa bibliothèque de classes, il ne s’agit même pas de classes. Je suis désolé, il y a longtemps que j'ai inventé le terme "objets" pour ce sujet, car beaucoup de gens se concentrent sur la moindre idée.
La grande idée est la "messagerie" - c’est l’objet même de Smalltalk / Squeak (et c’est quelque chose qui n’a jamais été complètement achevé au cours de la phase PARC de Xerox). Les Japonais ont un petit mot - ma - pour "ce qui est entre les deux" - peut-être l'équivalent anglais le plus proche est "interstitiel". La clé pour créer des systèmes performants et évolutifs réside bien plus dans la conception de la façon dont ses modules communiquent que sur leurs propriétés et leurs comportements internes. Pensez à Internet - pour vivre, il (a) doit permettre différents types d’idées et de réalisations qui dépassent toutes les normes et (b) permettre un degré variable d’interopérabilité en toute sécurité entre ces idées.
(Bien sûr, aujourd'hui, la plupart des gens ne se concentrent même pas sur des objets mais sur des classes, ce qui est encore plus faux.)
La messagerie est fondamentale pour OO, à la fois en tant que métaphore et en tant que mécanisme.
Si vous envoyez un message à quelqu'un, vous ne savez pas ce qu'il en fait. La seule chose que vous pouvez observer, c'est leur réponse. Vous ne savez pas s'ils ont traité le message eux-mêmes (c'est-à-dire si l'objet a une méthode), s'ils ont transmis le message à quelqu'un d'autre (délégation / proxy), s'ils l'ont même compris. C’est ce que l’encapsulation est, l’objet OO. Vous ne pouvez même pas distinguer un proxy de la réalité, tant qu'il répond à vos attentes.
Un terme plus "moderne" pour "messagerie" est "envoi de méthode dynamique" ou "appel de méthode virtuelle", mais il perd la métaphore et se concentre sur le mécanisme.
Il y a donc deux façons de regarder la définition d'Alan Kay: si vous la regardez seule, vous remarquerez peut-être que la messagerie est essentiellement un appel de procédure à liaison tardive et que la liaison tardive implique une encapsulation, ce qui permet de conclure que # 1 et # 2 sont en fait redondants, et OO est tout au sujet de la liaison tardive.
Cependant, il a plus tard précisé que l’important était la messagerie, et nous pouvons donc la regarder sous un angle différent: la messagerie est en retard. Maintenant, si la messagerie était la seule chose possible, alors le n ° 3 serait trivialement vrai: s'il n'y a qu'une seule chose, et que cette chose est en retard, toutes les choses sont en retard. Et encore une fois, l’encapsulation découle de la messagerie.
Des points similaires sont également présentés dans le document intitulé Comprendre l'abstraction des données, revisité par William R. Cook, ainsi que dans sa proposition de définitions modernes et simplifiées des termes "objet" et "orienté objet" :
La répartition dynamique des opérations est la caractéristique essentielle des objets. Cela signifie que l'opération à appeler est une propriété dynamique de l'objet lui-même. Les opérations ne peuvent pas être identifiées statiquement, et il n’ya généralement aucun moyen de [savoir] exactement quelle opération sera exécutée en réponse à une demande donnée, sauf en l’exécutant. C'est exactement la même chose que pour les fonctions de première classe, qui sont toujours distribuées dynamiquement.
Dans Smalltalk-72, il n'y avait même pas d'objets! Il n'y avait que des flux de message qui a obtenu analysables, réécrite et réacheminés. Les premières méthodes sont venues (méthodes standard pour analyser et rediriger les flux de messages), puis les objets (groupes de méthodes qui partagent un état privé). L'héritage est venu beaucoup plus tard, et les classes n'ont été introduites que comme un moyen de supporter l'héritage. Si le groupe de recherche de Kay était déjà au courant des prototypes, ils n'auraient probablement jamais introduit de cours.
Benjamin Pierce, dans Types et langages de programmation, affirme que la caractéristique qui définit l’objet Orientation est la récursion ouverte .
Donc: selon Alan Kay, OO est tout sur la messagerie. Selon William Cook, OO concerne la répartition dynamique des méthodes (ce qui est en réalité la même chose). Selon Benjamin Pierce, OO est une affaire de récursivité ouverte, ce qui signifie essentiellement que les auto-références sont résolues de manière dynamique (ou du moins que c'est une façon de penser), ou, en d'autres termes, la messagerie.
Comme vous pouvez le constater, la personne qui a inventé le terme "OO" a une vision plutôt métaphysique des objets, Cook a une vision plutôt pragmatique et Pierce une vision mathématique très rigoureuse. Mais l’important est que le philosophe, le pragmatiste et le théoricien soient tous d’accord! La messagerie est le seul pilier de OO. Période.
Notez qu'il n'y a aucune mention d'héritage ici! L'héritage n'est pas essentiel pour OO. En général, la plupart des langages OO ont un moyen de réutiliser une implémentation, mais cela ne doit pas nécessairement être un héritage. Cela pourrait aussi être une forme de délégation, par exemple. En fait, le Traité d’Orlando examine la délégation comme une alternative à l’héritage et explique comment les différentes formes de délégation et d’héritage conduisent à différents points de conception dans l’espace de conception des langages orientés objet. (Notez qu'en réalité, même dans les langages qui supportent l'héritage, comme Java, les gens apprennent à l'éviter, ce qui indique encore une fois que ce n'est pas nécessaire pour OO.)