Remarque
L’accès à cette page nécessite une autorisation. Vous pouvez essayer de vous connecter ou de modifier des répertoires.
L’accès à cette page nécessite une autorisation. Vous pouvez essayer de modifier des répertoires.
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 parties de leurs propres implémentations. L’une des façons de procéder dans Microsoft Visual C++ et d’autres langages consiste à utiliser l’héritage implementation, ce 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 de l’interaction entre objets à 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, il est implicite et ambigu. Lorsque l’objet parent ou enfant modifie son implémentation, le comportement des composants associés peut devenir indéfini ou instable. 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 par le biais de la réutilisation de boîte noire d’autres composants créés par d’autres équipes, ce type d’instabilité met en péril 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 impraticable pour les systèmes volumineux et évolutifs composés de composants logiciels créés par de nombreuses équipes d’ingénierie.
La clé de la création de composants réutilisables consiste à pouvoir traiter l’objet comme une boîte opaque. Cela signifie que l’élément de code qui tente de réutiliser un autre objet ne sait rien et ne doit rien savoir, à propos de la structure interne ou de l’implémentation du composant utilisé. 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 une réutilisation de boîte noire, COM adopte d’autres mécanismes de réutilisation déjà établis tels que la contenance/délégation et l’agrégation.
Note
Par souci de commodité, l’objet réutilisé est appelé l’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, ni n’a besoin de s’occuper, de la structure interne de l’objet externe- le client se soucie uniquement du comportement.
Pour plus d’informations, voir les rubriques suivantes :