Appuyez sur Entrée pour voir vos résultats ou Echap pour annuler.

Le code qui pue 2 – Trop de paramètres

Le deuxième article de la série sur les code smells traite d’un problème relativement fréquent, mais qui peut être difficile à résoudre et surtout à refactorer (refactoriser?). Pour ceuz qui avaient manqué le premier article, un code smells est une caractéristique plus ou moins commune du code qui indique pratiquement à tous coups un problème de conception sous-jacent.

Aujourd’hui, on traite du nombre de paramètres.

Quel est le nombre idéal de paramètres?

Un. Vous effectuez une seule opération sur un seul paramètre et retournez le résultat. Maximum deux, dans le cas où un paramètre serait nécessaire pour appliquer la seule opération sur le premier.

Mais Sylvain 😅 c’est impossible?!

Je te l’accorde. Mais avec un objectif comme ça, vous verrez plus rapidement les signes qu’un peu de refactoring est nécessaire.

En gros, le fait d’avoir un troisième paramètre devrait commencer à vous sonner des cloches. Rien n’est encore alarmant, car certains algorithmes peuvent nécessiter ce troisième argument. Par contre, c’est assez rare. Voici quelques symptômes communs.

Un membre de classe se cache dans les paramètres

Le principal symptôme serait de voir une méthode publique recevant un paramètre qui est ensuite passé à d’autres méthodes privées, ou qui serait aussi utilisé dans plus d’une méthode publique. Bref, lorsqu’un même paramètre revient plus d’une fois dans une même classe dans plusieurs méthodes, c’est souvent parce ce paramètre devrait être une propriété de la classe.

Dans ce cas précis, on peut remarquer que someNumber semble être un chiffre qui définit une caractéristique de l’objet, mais sans y être encapsulé. La valeur est fournie à l’objet via les paramètres de son API à répétition, donc elle devrait probablement être un attribut de la classe. La technique d’encapsulation peut être utilisée pour faire le refactoring.

Un objet se cache dans les paramètres

Ça peut être un peu plus difficile à trouver parce que l’ordre dans lequel ils apparaissent peut différer, mais ils se retrouvent toujours ensembles dans plusieurs fonctions.

L’exemple de plus flagrant :

On peut clairement voir dans l’exemple ci-dessus que x et y viennent toujours en paire et à plusieurs endroits dans le code. On peut simplement appliquer la technique d’introduction d’objet (dans le paramètre!), comme ceci :

La fonction ne respecte pas le SRP

Le principe de responsabilité unique (Single Responsibility Principle ou SRP) est un principe de l’orienté-objet qui peut, lorsque brisé, entraîner une augmentation du nombre de paramètres. En effet, si deux algorithmes distincts se cachent dans une fonction, il faudra que les paramètres nécessaires leurs soient passés.

L’exemple est tiré par les cheveux, mais imaginez que les system.out.println() sont des algorithmes distincts :

On peut utiliser une autre technique de refactoing appelée l’extraction de méthode :

Ainsi, on diminue le nombre de paramètres et permet une meilleure réutilisation de l’algorithme puisqu’il est maintenant scindé en deux.

J’ai soif 🍺

Aujourd’hui, vous avez appris un nouveau code smells avec ses symptômes les plus courants et quelques techniques pour les identifier et les retirer une bonne fois pour toute de votre code. Lorsqu’on développe, on ne pense pas nécessairement qu’un seul paramètre peut cacher un problème parce que les véritables symptômes arrivent beaucoup plus tard dans le développement. la plupart du temps, c’est à la veille de la mise en production…

À la prochaine! Merci de partager avec vos collègues 🙂

Suivez-nous par courriel!

Saisissez votre adresse courriel pour vous abonner au blog d'Ezo et recevoir une notification de chaque nouvel article par email.

Rejoignez 12 autres abonnés