Limitation de l'extensibilité en scellant des classes
Vous pouvez sceller des classes pour limiter les possibilités d'extension de l'infrastructure offertes aux développeurs. Lorsque vous scellez une classe, les autres classes ne peuvent pas en hériter. Lorsque vous scellez un membre, les classes dérivées ne peuvent pas substituer l'implémentation du membre. Vous ne devez pas sceller les types et les membres par défaut. Une telle action empêche la personnalisation des types et des membres de bibliothèque et fausse la perception de certains développeurs quant à leur utilité potentielle. De plus, l'extensibilité constitue l'un des avantages majeurs de l'utilisation d'une infrastructure orientée objet. Vous devez peser avec soin toute décision susceptible de neutraliser cet avantage.
Ne scellez pas de classes sans avoir une bonne raison de le faire.
Ne supposez pas qu'il est approprié de sceller une classe simplement parce que vous ne voyez pas de scénario dans lequel l'extension de la classe s'avère nécessaire ou utile. Seules les classes répondant à certaines conditions spécifiques doivent être scellées :
La classe est statique.
La classe contient des membres protégés hérités avec des informations de sécurité sensibles.
La classe hérite de nombreux membres virtuels et les coûts de développement et de test induits par le scellage de chaque membre sont nettement supérieurs à ceux requis pour sceller toute la classe.
La classe est un attribut exigeant une recherche rapide à l'aide de la réflexion. Le scellage d'un attribut améliore les performances de la réflexion lors de la récupération d'attributs.
Ne déclarez pas les membres virtuels ou protégés sur les types sealed.
Un type sealed ne peut pas avoir de classes dérivées. Il n'est possible d'accéder aux membres protégés qu'à partir d'une classe dérivée et les membres virtuels peuvent être substitués uniquement dans une classe dérivée.
Envisagez de sceller les membres que vous substituez.
Vous pouvez utiliser cette approche pour garantir que les classes dérivées ne puissent pas modifier ou ignorer un comportement requis pour la classe actuelle et toutes les classes dérivées.
Portions Copyright 2005 Microsoft Corporation. Tous droits réservés.
Portions Copyright Addison-Wesley Corporation. Tous droits réservés.
Pour plus d'informations sur les règles de conception, consultez « règles de conception d'infrastructure : Conventions idiomes et modèles carnet de bibliothèques réutilisables framework » Krzysztof Cwalina et Brad Abrams, publiés par Addison-Wesley, 2005.
Voir aussi
Concepts
Autres ressources
Instructions de conception pour le développement de bibliothèques de classes