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.
Les méthodes d’extension sont une fonctionnalité de langage qui permet aux méthodes statiques d’être appelées à l’aide de la syntaxe d’appel de méthode d’instance. Ces méthodes doivent prendre au moins un paramètre, qui représente l’instance sur laquelle la méthode doit fonctionner.
La classe qui définit de telles méthodes d’extension est appelée classe « sponsor » et doit être déclarée comme statique. Pour utiliser des méthodes d’extension, vous devez importer l’espace de noms définissant la classe de sponsor.
❌ ÉVITEz de définir de manière frivole les méthodes d’extension, en particulier sur les types que vous ne possédez pas.
Si vous possédez un code source d’un type, envisagez plutôt d’utiliser des méthodes d’instance régulières. Si vous ne possédez pas, et que vous souhaitez ajouter une méthode, soyez très prudent. L’utilisation libérale des méthodes d’extension a le potentiel d’encombrement des API de types qui n’ont pas été conçues pour avoir ces méthodes.
✔️ ENVISAGEZ d’utiliser des méthodes d’extension dans l’un des scénarios suivants :
Pour fournir des fonctionnalités d’assistance pertinentes pour chaque implémentation d’une interface, si cette fonctionnalité peut être écrite en termes d’interface principale. Cela est dû au fait que des implémentations concrètes ne peuvent pas être affectées à des interfaces. Par exemple, les
LINQ to Objectsopérateurs sont implémentés en tant que méthodes d’extension pour tous les IEnumerable<T> types. Par conséquent, touteIEnumerable<>implémentation est automatiquement activée par LINQ.Lorsqu’une méthode d’instance introduit une dépendance sur un type quelconque, mais une telle dépendance interrompt les règles de gestion des dépendances. Par exemple, une dépendance de String vers System.Uri n’est probablement pas souhaitable, et donc, du point de vue de la gestion des dépendances, la méthode d’instance
String.ToUri()retournantSystem.Uriserait la mauvaise conception. Une méthode d'extension statiqueUri.ToUri(this string str)retournantSystem.Uriserait une bien meilleure conception.
❌ ÉVITEZ de définir les méthodes d’extension sur System.Object.
Les utilisateurs VB ne pourront pas appeler de telles méthodes sur des références d’objet à l’aide de la syntaxe de méthode d’extension. VB ne prend pas en charge l’appel de ces méthodes, car, dans VB, la déclaration d’une référence en tant qu’objet force tous les appels de méthode sur celui-ci à être liés tardivement (le membre réel appelé est déterminé au moment de l’exécution), tandis que les liaisons aux méthodes d’extension sont déterminées au moment de la compilation (liaison anticipée).
Notez que la directive s’applique à d’autres langages où le même comportement de liaison est présent ou où les méthodes d’extension ne sont pas prises en charge.
❌ NE PAS placer les méthodes d’extension dans le même espace de noms que le type étendu, sauf s’il s’agit d’ajouter des méthodes à des interfaces ou pour la gestion des dépendances.
❌ ÉVITEz de définir deux méthodes d’extension ou plus avec la même signature, même si elles résident dans des espaces de noms différents.
✔️ ENVISAGEZ de définir des méthodes d’extension dans le même espace de noms que le type étendu si le type est une interface et si les méthodes d’extension sont destinées à être utilisées dans la plupart ou dans tous les cas.
❌ Ne définissez pas les méthodes d’extension implémentant une fonctionnalité dans les espaces de noms normalement associés à d’autres fonctionnalités. Au lieu de cela, définissez-les dans l’espace de noms associé à la fonctionnalité à laquelle ils appartiennent.
❌ ÉVITEZ le nommage générique des espaces de noms dédiés aux méthodes d’extension (par exemple, « Extensions »). Utilisez un nom descriptif (par exemple, « Routage ») à la place.
Portions © 2005, 2009 Microsoft Corporation. Tous 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.