Choix entre des classes et des interfaces
Mise à jour : novembre 2007
Une interface définit les signatures d'un ensemble de membres qui doivent être fournis par les implémenteurs. Les interfaces ne peuvent pas fournir de détails d'implémentation pour les membres. Par exemple, l'interface ICollection définit des membres associés à l'utilisation de collections. Chaque classe qui implémente l'interface doit fournir les détails d'implémentation de ces membres. Les classes peuvent implémenter plusieurs interfaces.
Les classes définissent à la fois les signatures des membres et les détails d'implémentation relatifs à chaque membre. Les classes Abstract (MustInherit en Visual Basic) peuvent se comporter comme des interfaces ou des classes normales en cela qu'elles peuvent définir des membres. Elles peuvent également fournir des détails d'implémentation mais ce n'est pas obligatoire. Si une classe abstraite ne fournit pas de détails d'implémentation, les classes concrètes héritant de la classe abstraite sont requises pour fournir l'implémentation.
Si les classes et les interfaces abstraites prennent en charge la dissociation du contrat et de l'implémentation, les interfaces ne peuvent pas spécifier de nouveaux membres dans les versions ultérieures alors que les classes abstraites peuvent ajouter autant de membres que nécessaire pour prendre en charge les fonctionnalités supplémentaires.
Définissez de préférence des classes plutôt que des interfaces.
Dans les versions ultérieures de votre bibliothèque, vous pouvez ajouter sans risque de nouveaux membres aux classes tandis que vous ne pouvez pas ajouter de membres aux interfaces sans provoquer l'arrêt du code existant.
Définissez une interface si vous devez fournir une hiérarchie polymorphe des types valeur.
Les types valeur doivent hériter de ValueType et peuvent hériter uniquement de ValueType. Dès lors, ils ne peuvent pas utiliser de classes pour séparer le contrat de l'implémentation. Dans ce cas, vous devez utiliser une interface si vos types valeur exigent un comportement polymorphe.
Envisagez de définir des interfaces pour accomplir un effet semblable à celui de l'héritage multiple.
Si un type doit implémenter plusieurs contrats ou si le contrat est applicable à un large éventail de types, utilisez une interface. Par exemple, l'interface IDisposable est implémentée par des types utilisés dans de nombreux scénarios différents. Exiger des classes qu'elles héritent d'une classe de base la possibilité d'être supprimées rendrait la hiérarchie de classes trop rigide. Des classes telles que MemoryStream qui doivent hériter leurs contrats basés sur les flux de données de leurs classes parentes ne seraient pas en mesure de le faire et d'être en même temps « supprimables ».
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 instructions de conception, consultez le livre « Framework Design Guidelines: Conventions, Idioms, and Patterns for Reusable .NET Libraries » de Krzysztof Cwalina et Brad Abrams, publié par Addison-Wesley, 2005.
Voir aussi
Concepts
Choix entre des classes et des structures
Autres ressources
Instructions de conception de types
Instructions de conception pour le développement de bibliothèques de classes