Discussion :

[nah666]

Bonjour,

Suite à ma relecture du livre 'coder proprement'
(http://www.pearson.fr/livre/?GCOI=27440100643800)

J'ai été interpellé par un passage et je viens ici vous demander votre avis:

L'auteur explique clairement que l'idéal est d'avoir 0 arguments dans les fonctions, 1 ou 2 si on ne peut pas faire autrement, 3 doit être exceptionnel et > 3 est une erreur d'archi/conception.

Même si je comprend ses arguments, j'ai du mal à percevoir le gros avantage qu'apporterait une refacto dans ce sens, aussi, dans mes divers projets, c'est une règle qui n'est rarement mise en avant.

Voici donc mes questions :

- Que pensez vous de cette 'bonne pratique' ?
- L'avez vous déjà vue respectée dans un projet, et quels en étaient les bénéfices ?


En espérant être sur le bon forum..

Merci d'avance,

[Luckyluke34]

Je vois 2 mauvaises raisons pour lesquelles on pourrait être tenté de passer beaucoup de paramètres à une méthode :

• On essaie de gérer des combinaisons de plein de cas différents à l'intérieur de la méthode. Dans ce cas les paramètres sont un mélange de booléens et de données servant aux différents cas. Le problème, c'est qu'on se retrouve avec une forêt de if qui est un cauchemar à maintenir et rien de réutilisable ailleurs.
  
  => A la place, déporter les différents comportements dans des classes à eux en se reposant sur le polymorphisme et l'injection de dépendance et/ou des patterns comme Stratégie et préférer la composition au passage de multiples paramètres à une méthode. Cela veut aussi peut-être dire que la méthode en question a trop de responsabilités et devrait être éclatée.

• On passe en paramètre de la méthode plein de données sans se rendre compte qu'elles forment une structure de données cohérente qui ferait un bon candidat pour être une entité en soi.
  
  => en faire une classe à part entière et passer en paramètre de la méthode une instance de cette classe.

Il y a sans doute aussi de temps en temps de bonnes raisons d'avoir une méthode avec plein d'arguments (construction d'un DTO ou d'un wrapper qui reprend tous les membres de la classe d'origine ?...), mais je n'ai pas souvent rencontré ce cas de figure.