La délégation des langages à prototypes

Les langages à prototypes offrent une alternative aux langages basés sur des classes dans la POO (Lieberman, 1986)(Myers, Giuse, & Zanden, 1992). Ils offrent un modèle de création flexible qui permet le partage de propriétés et de comportement. De tels mécanismes permettent aux utilisateurs de structurer une hiérarchie de prototypes et d’agir sur un ou plusieurs clones en manipulant un prototype dans la hiérarchie de délégation avec plus de flexibilité qu’avec un modèle de hiérarchies de classes.

Dans la POO classique, l’héritage catégorise les objets en classes qui décrivent le comportement de leurs instances. Le concept de classe devient obsolète dès lors que l’on raisonne en prototypes. Un prototype représente le comportement par défaut d’un concept. D’autres nouveaux objets peuvent alors réutiliser tout ou partie des caractéristiques du premier prototype et se démarquer en spécifiant quelles caractéristiques diffèrent entre eux. La délégation est le mécanisme permettant d’implémenter le concept de prototypes dans la POO (Lieberman, 1986).

L’inconvénient des classes est qu’elles doivent toutes être crées obligatoirement avant les instances que l’on souhaite utiliser et le comportement de ces instances ne peut être associé qu’avec des classes. Parce que n’importe quel objet peut être utilisé en tant que prototype et que l’on peut déléguer et partager des propriétés entre les objets à tout moment, la délégation s’avère donc bien plus flexible et permissive. Cela laisserait à penser que les techniques de structurations explicites par le biais d’objets abstraits telle que les classes (par exemple les masters) seraient donc moins efficaces pour la création et la manipulation d’objets graphiques que des techniques basées sur la délégation.

Pour mieux comprendre le concept de délégation et la différence avec la classification, Lieberman présente l’exemple de Clyde, un éléphant. En raisonnant en « classes », l’on peut se dire que pour que l’existence d’un éléphant Clyde ainsi que celle d’un éléphant Fred soit possible, il faut que l’on accède à une classe, probablement « éléphant », qui détienne l’ensemble des attributs minimalistes que doivent avoir tous les éléphants. Clyde et Fred sont alors chacun une instance de la classe éléphant. Pour raisonner en « prototypes », l’on peut considérer que l’on a un éléphant : Clyde. Il existe, c’est un prototype. Si l’on veut pouvoir définir une autre entité (l’éléphant Fred) ayant des caractéristiques communes avec Clyde, il suffit de demander à Clyde de déléguer tout ou partie de ses propriétés à Fred, le nouveau prototype, qui peut se contenter d’exprimer quelles sont les différences qui le démarquent de Clyde. La Figure 39 illustre cet exemple.

Figure 39. A gauche, Clyde et Fred sont deux instances de la classe « éléphant », et ont des valeurs de propriétés qui leur sont propres. A droite, Clyde est un prototype d’éléphant qui délègue ses

propriétés à Fred. Fred est alors comme Clyde, à la différence près qu’il est bleu.

La délégation supprime la distinction entre classes et instances, tous les objets peuvent servir de prototypes. La délégation est alors très avantageuse pour le développement interactif et incrémental, puisqu’il n’est pas nécessaire de réfléchir à une structure au préalable. Cela encourage l’exploration et diminue la barrière d’abstraction ainsi que l’engagement prématuré.

Les avantages des langages à prototypes face aux langages à base de classes ont encouragé des chercheurs à proposer des systèmes et environnements permettant la création et la manipulation de prototypes. Self est un langage de programmation orienté-objet basé sur les prototypes (Ungar & Smith, 1987).

Figure 40. Présentation de Self 4.45 _{et de son interface utilisateur, Morphic.}

Les objets graphiques sont des morphes qui dépendent de prototypes dont les liens de parenté sont représentés par les traits oranges.

Morphic (Figure 40) est un kit de construction d’interfaces utilisateurs basé sur le langage Self qui réifie des prototypes et des clones en objets graphiques et permet leur construction et leur édition via manipulation directe (Maloney & Smith, 1995). L’un des buts avoués de Morphic étant de faciliter la construction ainsi que l’édition d’objets graphiques interactifs, ils constituent alors l’abstraction centrale de Morphic, et sont appelés « morphes » (du grec pour forme). Les morphes peuvent être composés d’autres morphes, des « submorphs », décrivant ainsi une agrégation de morphes analogue à une hiérarchie de prototypes et détenant les avantages de ces dernières : une grande flexibilité et un pouvoir d’action augmenté pour la manipulation d’éléments graphiques.

(Myers et al., 1992) présentent le système Garnet, un environnement offrant aux programmeurs la capacité d’écrire du code avec un langage à prototypes. Garnet repose sur KR (Knowledge Representation), un « moteur » logiciel modélisant des

5 _{Self 4.4 est la dernière version du langage. Documentation et téléchargement disponibles sur}

connaissances liées par des contraintes. Dans Garnet, les objets sont persistants et reçoivent les entrées des utilisateurs, ce qui en fait un système efficace pour le développement d’interfaces graphiques. Sa force vient donc de celle des langages à prototypes : le partage de propriétés entre un prototype et ses instances, la rapidité de mise en œuvre, et les modifications dynamiques. Le style de programmation dans Garnet se veut donc différent des autres systèmes des langages à objets. Le programmeur crée ses objets graphiques avec des outils interactifs, écrit les contraintes pour définir des relations et ensuite associe les instances à des interacteurs prédéfinis.