Implémentation explicite de membres d'interface
Mise à jour : novembre 2007
Une interface est un contrat de prise en charge de certaines fonctionnalités. Les classes qui implémentent une interface doivent fournir les détails d'implémentation des membres spécifiés dans l'interface. Par exemple, l'interface IEnumerator définit les signatures des membres qu'il est nécessaire d'implémenter pour prendre en charge l'énumération sur un ensemble d'objets, par exemple une collection. Pour implémenter IEnumerator, une classe doit implémenter les membres Current, MoveNext et Reset.
Lorsqu'un membre d'interface est implémenté explicitement par une classe, seule une référence à l'interface permet d'accéder au membre. Cela revient à masquer le membre d'interface. Une des raisons justifiant souvent l'implémentation explicite d'un membre d'interface est non seulement le respect du contrat de l'interface mais aussi son amélioration (par exemple, en fournissant des méthodes fortement typées au lieu des méthodes faiblement typées de l'interface). Par ailleurs, l'implémentation explicite d'un membre d'interface est également conseillée lorsque le membre d'interface explicite ne doit pas être appelé par des développeurs. Par exemple, le membre GetObjectData est très souvent implémenté explicitement car il est appelé par l'infrastructure de sérialisation et ne doit pas être appelé à partir du code.
Les instructions de conception suivantes garantissent que votre design de bibliothèque utilise l'implémentation d'interface explicite uniquement dans les circonstances appropriées.
Évitez d'implémenter explicitement des membres d'interface si vous n'avez pas de bonne raison de le faire.
Le fonctionnement de l'implémentation explicite requiert un niveau de compétence avancé. Ainsi, de nombreux développeurs ne savent pas qu'un membre implémenté explicitement peut être appelé publiquement bien que sa signature soit privée. C'est la raison pour laquelle les membres implémentés explicitement n'apparaissent pas dans la liste des membres visibles publiquement. L'implémentation explicite d'un membre peut également provoquer une conversion boxing inutile des types valeur.
Envisagez d'implémenter explicitement des membres d'interface si les membres sont destinés à être appelés uniquement via l'interface.
Cela inclut principalement les membres qui prennent en charge l'infrastructure du .NET Framework, telle que la liaison de données ou la sérialisation. Par exemple, la propriété IsReadOnly est accessible uniquement pour l'infrastructure de liaison de données à l'aide d'une référence à l'interface ICollection<T>. La classe List<T> implémente la propriété explicitement parce qu'elle est conforme à cette instruction.
Envisagez d'implémenter explicitement des membres d'interface pour simuler la variance (c'est-à-dire modifier des paramètres ou le type de retour dans les membres substitués).
Cela sert généralement à fournir des versions fortement typées des membres d'interface.
Envisagez d'implémenter explicitement des membres d'interface pour masquer un membre et ajouter un membre équivalent avec un nom plus approprié.
Le membre est alors effectivement renommé. Par exemple, Stream implémente explicitement Dispose et fournit la méthode Close à sa place.
N'utilisez pas de membres explicites en tant que limite de sécurité.
L'implémentation explicite d'un membre ne fournit aucune sécurité. Ces membres peuvent être appelés publiquement à l'aide d'une référence à l'interface.
Fournissez un membre virtuel protégé qui offre les mêmes fonctionnalités que le membre explicitement implémenté si les fonctionnalités sont destinées à être spécialisées par des classes dérivées.
Les membres explicitement implémentés ne peuvent pas être substitués. S'ils sont redéfinis dans une classe dérivée, il est impossible pour la classe dérivée d'appeler l'implémentation de la classe de base. Vous devez soit attribuer au membre protégé le même nom que le membre d'interface explicite, soit apposer Core au nom du membre d'interface.
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
Autres ressources
Instructions de conception des membres
Instructions de conception pour le développement de bibliothèques de classes