Réutilisation d’objets

Un objectif important de tout modèle objet est de permettre aux auteurs d’objets de réutiliser et d’étendre les objets fournis par d’autres en tant que morceaux de leurs propres implémentations. Une façon de procéder dans Microsoft Visual C++ et d’autres langages consiste à utiliser l’héritage d’implémentation, qui permet à un objet d’hériter (« sous-classe ») de certaines de ses fonctions d’un autre objet tout en remplaçant d’autres fonctions.

Le problème pour l’interaction d’objet à l’échelle du système à l’aide de l’héritage d’implémentation traditionnel est que le contrat (l’interface) entre les objets d’une hiérarchie d’implémentation n’est pas clairement défini. En fait, elle est implicite et ambiguë. Lorsque l’objet parent ou enfant modifie son implémentation, le comportement des composants associés peut devenir non défini ou implémenté de manière inétérée. Dans n’importe quelle application unique, où l’implémentation peut être gérée par une seule équipe d’ingénierie qui met à jour tous les composants en même temps, ce n’est pas toujours une préoccupation majeure. Dans un environnement où les composants d’une équipe sont créés via la réutilisation en boîte noire d’autres composants créés par d’autres équipes, ce type d’instabilité compromet la réutilisation. En outre, l’héritage d’implémentation fonctionne généralement uniquement dans les limites du processus. Cela rend l’héritage d’implémentation traditionnel peu pratique pour les systèmes volumineux et évolutifs composés de composants logiciels créés par de nombreuses équipes d’ingénierie.

La clé pour créer des composants réutilisables est de pouvoir traiter l’objet comme une boîte opaque. Cela signifie que le morceau de code qui tente de réutiliser un autre objet ne sait rien de la structure interne ou de l’implémentation du composant utilisé et ne doit rien savoir. En d’autres termes, le code qui tente de réutiliser un composant dépend du comportement de l’objet et non de son implémentation exacte.

Pour obtenir la réutilisabilité en boîte noire, COM adopte d’autres mécanismes de réutilisation établis, tels que le confinement/délégation et l’agrégation.

Notes

Pour des raisons pratiques, l’objet réutilisé est appelé objet interne et l’objet qui utilise cet objet interne est l’objet externe.

 

Il est important de se rappeler dans ces deux mécanismes comment l’objet externe apparaît à ses clients. En ce qui concerne les clients, les deux objets implémentent toutes les interfaces vers lesquelles le client peut obtenir un pointeur. Le client traite l’objet externe comme une boîte opaque et ne se soucie donc pas de la structure interne de l’objet externe.

Pour plus d'informations, voir les rubriques suivantes :

• Confinement/délégation
• Agrégation