Classes de base pour l'implémentation d'abstractions
Remarque
Ce contenu est réimprimé avec l’autorisation de Pearson Education, Inc. à partir des Instructions de conception d’une infrastructure : conventions, idiomes et modèles des bibliothèques réutilisables .NET, 2ème édition. Cette édition a été publiée en 2008, et le livre a été entièrement révisé dans la troisième édition. Certaines informations de cette page peuvent être obsolètes.
À proprement parler, une classe devient une classe de base lorsqu’une autre classe en est dérivée. Toutefois, dans le cadre de cette section, une classe de base est une classe conçue principalement pour fournir une abstraction commune ou pour que d’autres classes réutilisent une implémentation par défaut par héritage. Les classes de base se trouvent généralement au milieu des hiérarchies d’héritage, entre une abstraction à la racine d’une hiérarchie et plusieurs implémentations personnalisées en bas.
Elles servent d’assistances d’implémentation pour l’implémentation d’abstractions. Par exemple, l’une des abstractions de l’infrastructure pour les collections ordonnées d’éléments est l’interface IList<T>. L’implémentation IList<T> n’est pas triviale, et par conséquent, l’infrastructure fournit plusieurs classes de base, telles que Collection<T> et KeyedCollection<TKey,TItem>, qui servent d’assistance pour l’implémentation de collections personnalisées.
Les classes de base ne sont généralement pas adaptées pour servir d’abstractions par elles-mêmes, car elles ont tendance à contenir trop d’implémentation. Par exemple, la classe de base Collection<T> contient un grand nombre d’implémentations liées au fait qu’elle implémente l’interface IList non générique (pour mieux s’intégrer aux collections non génériques) et au fait qu’il s’agit d’une collection d’éléments stockés en mémoire dans l’un de ses champs.
Comme indiqué précédemment, les classes de base peuvent fournir une aide précieuse aux utilisateurs qui ont besoin d’implémenter des abstractions, mais en même temps, elles peuvent être une responsabilité importante. Elles ajoutent une surface d’exposition et augmentent la profondeur des hiérarchies d’héritage, et compliquent donc conceptuellement l’infrastructure. Par conséquent, les classes de base ne doivent être utilisées que si elles fournissent une valeur significative aux utilisateurs de l’infrastructure. Elles doivent être évitées si elles fournissent une valeur uniquement aux implémenteurs de l’infrastructure, auquel cas la délégation à une implémentation interne doit être fortement prise en compte, au lieu de l’héritage d’une classe de base.
✔️ ENVISAGEZ de créer des classes de base abstraites même si elles ne contiennent aucun membre abstrait. Cela communique clairement aux utilisateurs que la classe est conçue uniquement pour être héritée.
✔️ ENVISAGEZ de placer des classes de base dans un espace de noms distinct des types de scénarios principaux. Par définition, les classes de base sont destinées à des scénarios d’extensibilité avancés et ne sont donc pas intéressantes pour la majorité des utilisateurs.
❌ ÉVITEZ de nommer des classes de base avec un suffixe « Base » si la classe est destinée à être utilisée dans des API publiques.
Portions © 2005, 2009 Microsoft Corporation. Tous droits réservés.
Réimprimé avec l’autorisation de Pearson Education, Inc. et extrait de Framework Design Guidelines: Conventions, Idioms, and Patterns for Reusable .NET Libraries, 2nd Edition par Krzysztof Cwalina et Brad Abrams, publié le 22 octobre 2008 par Addison-Wesley Professional dans le cadre de la série sur le développement Microsoft Windows.