Conception de classes abstraites
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.
❌ NE DÉFINISSEZ PAS des constructeurs internes publics ou protégés dans des types abstract.
Les constructeurs doivent être publics uniquement si les utilisateurs ont besoin de créer des instances du type. Étant donné que vous ne pouvez pas créer des instances d’un type abstract, un type abstract avec un constructeur public est mal conçu et trompeur pour les utilisateurs.
✔️ DÉFINISSEZ un constructeur protégé ou interne dans des classes abstraites.
Un constructeur protégé est plus courant et permet simplement à la classe de base d’effectuer sa propre initialisation lors de la création de sous-types.
Un constructeur interne peut être utilisé pour limiter les implémentations concrètes de la classe abstraite à l’assembly qui définit la classe.
✔️ FOURNISSEZ au moins un type concret qui hérite de chaque classe abstraite que vous expédiez.
Cela permet de valider la conception de la classe abstraite. Par exemple, System.IO.FileStream est une implémentation de la classe abstraite System.IO.Stream.
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.