Méthodes d’extension

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 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 d’utiliser plutôt des méthodes d’instance régulières. Si vous n’en 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 n’importe lequel 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 attribuées à des interfaces. Par exemple, les opérateurs LINQ to Objects sont implémentés en tant que méthodes d’extension pour tous les types IEnumerable<T>. Par conséquent, toute implémentation IEnumerable<> est automatiquement activée par LINQ.

• Lorsqu’une méthode d’instance introduit une dépendance sur un type quelconque, mais qu’une telle dépendance interrompt les règles de gestion des dépendances. Par exemple, une dépendance de String à System.Uri n’est probablement pas souhaitable, et la méthode d’instance String.ToUri() retournant System.Uri serait donc la mauvaise conception du point de vue de la gestion des dépendances. Une méthode d’extension statique Uri.ToUri(this string str) retournant System.Uri serait une meilleure conception.

❌ ÉVITEZ de définir les méthodes d’extension sur System.Object.

Les utilisateurs de 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 limité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 (limite anticipée).

Notez que la directive s’applique à d’autres langages dans lesquels le même comportement de liaison est présent ou dans lesquels les méthodes d’extension ne sont pas prises en charge.

❌ NE placez PAS les méthodes d’extension dans le même espace de noms que le type étendu, sauf pour 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. Définissez-les plutôt dans l’espace de noms associé à la fonctionnalité à laquelle elles appartiennent.

❌ ÉVITEZ de nommer de manière générique les 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é avec l’autorisation de Pearson Education, Inc. et extrait de Framework Design Guidelines: Conventions, Idioms, and Patterns for Reusable .NET Libraries, 2nd Edition par Krzysztof Cwalina et Brad Abrams, publié le 22 octobre 2008 par Addison-Wesley Professional dans le cadre de la série sur le développement Microsoft Windows.

Voir aussi

• Instructions de conception des membres
• Règles de conception de .NET Framework