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 ces méthodes d’extension est appelée classe « sponsor » et doit être déclarée comme statique. Pour utiliser des méthodes d’extension, il faut 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 les implémentations concrètes ne peuvent pas être affectées à des interfaces. Par exemple, les LINQ to Objects opérateurs sont implémentés en tant que méthodes d’extension pour tous les IEnumerable<T> types. Ainsi, toute IEnumerable<> implémentation est automatiquement activée PAR LINQ.

  • Lorsqu’une méthode d’instance introduit une dépendance sur un certain type, mais qu’une telle dépendance interrompt les règles de gestion des dépendances. Par exemple, une dépendance à partir de String vers System.Uri n’est probablement pas souhaitable, et donc String.ToUri() la méthode d’instance retournée System.Uri serait la mauvaise conception d’une perspective de gestion des dépendances. Un retour System.Uri de méthode Uri.ToUri(this string str) d’extension statique serait une conception bien meilleure.

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

VB utilisateurs ne pourront pas appeler de telles méthodes sur des références d’objet à l’aide de la syntaxe de la méthode d’extension. VB ne prend pas en charge l’appel de ces méthodes, car, dans VB, déclarer une référence en tant qu’objet force tous les appels de méthode sur celui-ci à être lié 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 les instructions s’appliquent à 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 s’ils résident dans différents espaces de noms.

✔️ 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é 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