Thomas Lebrun

Un article que je recommande car le sujet est très bien amené et va à l'essentiel !

Idem

Bon travail thomas :-). En plus sur msdn c'est la classe :-)

Pour ceux qui préfère une pres en français à un article en anglais :p, j'avais réalisé un webcast sur les extension methods : ftp://ftp-developpez.com/matthieumezil/webcasts/ExtensionMethods.wmv

Un petit article simple et explicatif.

D'un autre côté il n'y a pas non beaucoup à dire sur les méthodes d'extension. Sauf peut-être que j'ajouterais un bémol à ton enthousiasme : faire sortir des méthodes du chapeau du magicien, méthodes qui n'appartiennent pas à la classe, ni à ses ancêtres ni même à une interface, je trouve ça particulièrement bordélique et une trop grande porte ouverte au code spaghetti...

Borland avait déjà implémenté ça dans Delphi 8.NET sous le même nom pour ajouter à System.Object les méthodes de TObject afin de simplifier le portage de la VCL.NET. Microsoft fait pareil pour simplifier le code LINQ dans C# 3.0.

A chaque fois que ce principe est utilisé c'est pour simplifier la vie de l'éditeur du langage, et cela ne me semble pas une "bonne" raison justifiée par une nécessité fonctionnelle. Pour moi ça sent toujours un peu le bricolage ces class helpers.

Et surtout, je redoute, en tant qu'auditeur et conseil, de tomber dans les mois à venir sur des applis C# qui deviendront impossibles à débugger à cause d'artifices de ce type mal utilisés.

A ce jour et sauf pour faire passer un System.Object pour un TObject(bidouille) ou simplifier la syntaxe de LINQ (excuse stylistique sans réel fondement technique), je ne vois aucun avantage aux class helpers, rien qui ne puisse être fait avec plus d'élégance en utilisant l'héritage et les interface.

Laissons les class helpers aux éditeurs de langage pour leur bidouillages internes, cela me semble préférable...

On ne peut pas tout adorer, sinon ça ferait adepte de la secte du grand gourou MS :-)