Du bon usage des méthodes d’extension en C# (partie 1)

Une revue de code a fait apparaître plus tôt aujourd’hui un joli cas de figure. En effet, une des équipes a développé un usage assez particulier des méthodes d’extension.

Pour rappel, les méthodes d’extension ont fait leur apparition avec C# 3, et permettent d’étendre des fonctionnalités d’une classe sans avoir à modifier cette dernière. L’exemple le plus visible est évidemment Linq, et les méthodes Any(),
GroupBy(), OrderBy() qui ont étendu les fonctionnalités de l’interface IEnumerable<T>.

Gardons néanmoins à l’esprit que les méthodes agissent sur des objets et non des classes. Une méthode d’extension n’appartenant pas à la classe qu’elle étend, elle n’a naturellement pas accès à ses méthodes, propriétés et variables privées et protégées.

N’importe qui peut donc étendre n’importe quelle classe, et notamment celles du Framework. C’est donc un ajout extrêmement puissant au langage. Il faut néanmoins éviter certains écueils. La première est de développer des méthodes d’extension sur des classes amenées à évoluer dans le futur. En effet, comme le précise cet article, la méthode d’extension ne sera jamais exécutée si la classe comporte une méthode native de signature identique. Le code peut donc changer totalement de comportement, sans aucun avertissement à la compilation.

Le second écueil est plus rigolo. Revenons donc à notre équipe de développeurs. Appelons-là équipe A. Donc l’équipe A développe une application, nécessitant une librairie MaSociete.Helpers.dll. Ils n’aiment pas toucher à cette librairie. Elle est vieille, bordélique, mal développée… Ou pire. Développée par l’équipe B (on les aime pas trop, eux, et puis c’est trop compliqué de synchroniser deux équipes de l’open space). Peu importe. Et il leur manque une méthode int GetIdFromPrettyUrl(string)… et – c’est apparemment une mauvaise habitude – décident d’écrire une méthode d’extension à la classe String : public static int GetIdFromPrettyUrl(this string url) dans une librairie qu’ils aiment mieux : MaSociete.NewHelpers.dll.

Alors oui, ça marche. Bien, même. Etait-ce pourtant une bonne idée. Non. La classe String a été étendue pour y ajouter du code métier. Première erreur. Où avons-nous maintenant du code métier portant sur les mêmes problématiques ? Dans MaSociete.Helpers.dll et MaSociete.NewHelpers.dll. Allez maintenir ça dans le temps et l’expliquer à un nouvel arrivant… C’est la deuxième erreur.

La troisième erreur – et non la moindre – est de se satisfaire de la dette technique. Un code dont on a la responsabilité ne doit pas rester à l’abandon. Si le code est mauvais, il faut justement le refactorer.

Les méthodes d’extension sont une fonctionnalité de C# que j’apprécie beaucoup. Notamment pour développer des Helpers avec une syntaxe extrêmement élégante. Mais attention à en faire bon usage, les pièges sont relativement nombreux sur la route.