Notes
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.
Remarque
Ce contenu est réimprimé avec l’autorisation de Pearson Education, Inc. tiré de Lignes directrices de conception de framework : Conventions, Idiomes et Modèles pour les bibliothèques .NET réutilisables, 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.
Bien que la plupart des API soient mieux modélisées à l’aide de classes et de structs, il existe des cas dans lesquels les interfaces sont plus appropriées ou sont la seule option.
Le CLR ne prend pas en charge plusieurs héritages (c’est-à-dire que les classes CLR ne peuvent pas hériter de plusieurs classes de base), mais elles permettent aux types d’implémenter une ou plusieurs interfaces en plus d’hériter d’une classe de base. Par conséquent, les interfaces sont souvent utilisées pour obtenir l’effet de plusieurs héritages. Par exemple, IDisposable est une interface qui permet aux types de gérer la disposabilité indépendamment de toute autre hiérarchie d’héritage à laquelle ils souhaitent participer.
L’autre situation dans laquelle la définition d’une interface est appropriée consiste à créer une interface commune qui peut être prise en charge par plusieurs types, y compris certains types valeur. Les types valeur ne peuvent pas hériter des types autres que ValueType, mais ils peuvent implémenter des interfaces. L’utilisation d’une interface est donc la seule option pour fournir un type de base commun.
✔️ Définissez une interface si vous avez besoin d’une API commune pour être prise en charge par un ensemble de types qui inclut des types de valeur.
✔️ ENVISAGEZ de définir une interface si vous devez prendre en charge ses fonctionnalités sur les types qui héritent déjà d’un autre type.
❌ ÉVITEZ d’utiliser des interfaces de marqueur (interfaces sans membres).
Si vous devez marquer une classe comme ayant une caractéristique spécifique (marqueur), en général, utilisez un attribut personnalisé plutôt qu’une interface.
✔️ Fournissez au moins un type qui est une implémentation d’une interface.
Cela permet de valider la conception de l’interface. Par exemple, List<T> il s’agit d’une implémentation de l’interface IList<T> .
✔️ Fournissez au moins une API qui consomme chaque interface que vous définissez (une méthode prenant l’interface en tant que paramètre ou propriété typée comme interface).
Cela permet de valider la conception de l’interface. Par exemple, List<T>.Sort utilise l’interface System.Collections.Generic.IComparer<T> .
❌ N’ajoutez pas de membres à une interface qui a précédemment été livrée.
Cela interrompt les implémentations de l’interface. Vous devez créer une interface pour éviter les problèmes de contrôle de version.
À l’exception des situations décrites dans ces instructions, vous devez, en général, choisir des classes plutôt que des interfaces dans la conception de bibliothèques réutilisables de code managé.
Portions © 2005, 2009 Microsoft Corporation. Tous les droits réservés.
Réimprimé par l’autorisation de Pearson Education, Inc. tiré de Framework Design Guidelines : Conventions, Idioms et Patterns pour les bibliothèques .NET réutilisables, 2e édition par Krzysztof Cwalina et Brad Abrams, publié le 22 octobre 2008 par Addison-Wesley Professional dans le cadre de la Série de développement Microsoft Windows.