Quelles sont les meilleures pratiques pour utiliser les méthodes d'extension en .Net ?

Question

J'ai vu ces produits utilisés dans tous les sens, et j'ai été accusé de les utiliser dans le mauvais sens (bien que dans ce cas, je les utilisais de cette façon pour démontrer un problème de sécurité). point ).

Alors, selon vous, quelles sont les meilleures pratiques pour utiliser les méthodes d'extension ?

Les équipes de développement doivent-elles créer une bibliothèque de méthodes d'extension et les déployer sur différents projets ?

Devrait-il y avoir une collection de méthodes d'extension communes sous la forme d'un projet open source ?

Mise à jour : nous avons décidé de créer une bibliothèque de méthodes d'extension à l'échelle de l'organisation.

Answer 1

Je vous recommande de consulter l'article de blog suivant :

http://blogs.msdn.com/vbteam/archive/2007/03/10/extension-methods-best-practices-extension-methods-part-6.aspx

Il contient quelques lignes directrices sur la manière d'utiliser les méthodes d'extension.

Je l'ai écrit à l'époque où je travaillais pour Microsoft, où j'étais le gars de l'équipe du compilateur VB qui implémentait les méthodes d'extension.

Answer 2

La prochaine version des Framework Design Guidelines, 2e édition, contiendra des conseils pour la mise en œuvre des méthodes d'extension, mais en général :

Vous ne devez définir des méthodes d'extension que "lorsqu'elles ont un sens sémantique" et qu'elles fournissent une fonctionnalité d'aide pertinente pour chaque mise en œuvre.

Vous devez également éviter d'étendre System.Object, car tous les langages .NET ne seront pas en mesure d'appeler la méthode d'extension comme une extension. (VB.NET, par exemple, devra l'appeler comme une méthode statique ordinaire sur la classe d'extension statique).

Ne définissez pas une méthode d'extension dans le même espace de noms que le type étendu, sauf si vous étendez une interface.

Ne définissez pas une méthode d'extension avec la même signature qu'une "vraie" méthode, car elle ne sera jamais appelée.

Answer 3

Vous pourriez vouloir jeter un coup d'oeil à http://www.codeplex.com/nxl y http://www.codeplex.com/umbrella qui sont toutes deux des bibliothèques de méthodes d'extension. Je n'ai personnellement pas jeté un coup d'œil au code source, mais je suis sûr que les gars là-bas seront en mesure de vous donner quelques bons conseils.

Answer 4

J'ai inclus mes méthodes d'extension avec mes bibliothèques Core dans la classe Utils parce que les personnes qui travaillent avec mon framework sont susceptibles de trouver les méthodes utiles, mais pour un déploiement de masse où le développeur final pourrait avoir un choix de bibliothèques de méthodes d'extension, je conseillerais de mettre toutes vos extensions dans leur propre espace de nom, même leur propre fichier de projet, de sorte que les gens peuvent choisir d'ajouter une référence ou une déclaration d'utilisation ou simplement où cela est nécessaire, comme ceci :

Core.Extensions.Base64Encode(str);

Ma classe Utils est ma meilleure amie au monde, c'était avant que les méthodes d'extension n'arrivent et elles n'ont fait que renforcer notre relation. La plus grande règle que je suivrais est de donner aux gens le choix du cadre d'extension qu'ils utilisent lorsque c'est possible.

Answer 5

Le langage Objective-C dispose de " catégories " depuis le début des années 1990 ; il s'agit essentiellement de la même chose que les méthodes d'extension .NET. Lorsque vous recherchez les meilleures pratiques, vous pouvez consulter les règles empiriques que les développeurs Objective-C (Cocoa et NeXT) ont élaborées à leur sujet.

Brent Simmons (l'auteur du lecteur de flux RSS NetNewsWire pour Mac OS X et iPhone) vient de publier aujourd'hui un message sur sa nouvelles règles de style pour l'utilisation des catégories et il y a eu un peu de discussion dans la communauté Cocoa autour de ce poste.