web-dev-qa-db-fra.com

Quand une méthode a trop de paramètres?

Lors du débogage d'un code client de service Web aujourd'hui (en Java, avec jax-ws), j'ai rencontré une méthode de service Web avec la quantité époustouflante de 97 paramètres!

J'ai dû créer un cas de test qui appelle cette méthode, et j'ai remarqué plusieurs choses:

  • l'assistance/le survol du code n'est pas bien à l'échelle. J'utilise Eclipse, et l'info-bulle sur la méthode est aussi large que l'écran et s'étend sur plusieurs lignes.
  • J'ai dû copier les valeurs des paramètres d'une capture xml précédente, et il était pratiquement impossible de se rappeler "où suis-je" - lorsque le curseur se trouvait après une virgule et avant de taper une valeur, je me trompais souvent de type de données - je tapais un entier au lieu d'une chaîne et vice versa.
  • Même après avoir écrit tous les paramètres, j'avais encore quelques erreurs et la signature ne correspondait pas. Malheureusement, Eclipse marque toute la ligne en rouge comme ayant une erreur, donc trouver où l'erreur a pris encore plus de temps :(

Donc, cela m'a fait réfléchir, à votre avis, quel est le nombre sain de paramètres maximum pour une méthode? Et si vous pouviez changer cette signature de service Web, comment pensez-vous qu'elle puisse être améliorée?

language-agnosticideparameters
39
Yoni

Il n'y a pas de limite claire, mais je suis mal à l'aise avec plus de 3-4 paramètres. AFAIR Oncle Bob Martin dans Clean Code recommande max 3.

Il existe plusieurs refactorings pour réduire le nombre de paramètres de méthode (voir Travailler efficacement avec le code hérité , par Michael Feathers pour plus de détails). Cela me vient à l'esprit:

  • encapsuler de nombreux paramètres associés dans un seul objet (par exemple, au lieu de String surName, String firstName, String streetAddress, String phoneNumber passez un Person objet les contenant comme champs)
  • passer des paramètres dans le constructeur ou d'autres appels de méthode avant l'invocation de cette méthode
65
Péter Török

Quand vous devez demander, c'est probablement trop.

34
user151323

Comme Steve McConnell le mentionne dans Code Complete , la règle d'or est de 4 +/- 3 paramètres. Pour un humain moyen, il est difficile de se souvenir de plus de 4 paramètres, 5-7 doit être utilisé uniquement dans des cas spéciaux et vous ne devez jamais en utiliser 8 ou plus.

12
Ondrej Slinták

Grand Bouddha !! Quatre-vingt-dix-sept????

Les bonnes pratiques conseillent généralement environ max. six à huit. Bien sûr, ymmv, et il peut y avoir une raison valable, de temps en temps, pour un neuvième. Mais 97 ?? !!

Quelques réflexions ... s'agit-il simplement de données, ou les décisions sont-elles prises en fonction de leurs valeurs?

Si plusieurs/la plupart affectent le contrôle de flux, vous avez une "conception" presque impossible à maintenir (même compréhensible ou testable) (pour les petites valeurs de "conception").

S'ils ne sont que des données, peuvent-ils être regroupés en structures et pointeurs de ces structures transmises?

Avez-vous une documentation de conception? Cela pourrait-il expliquer ce qui se passe?.

Oh, et "Danger, Will Robinson" - toute personne qui passera 97 paramètres ouvertement pourrait également passer n'importe quel nombre - pas si évidemment - en tant que variables globales.

Les P. ne savent pas comment Eclipse fonctionne sur Java, mais avec C/C++, si vous placez les paramètres sur des lignes distinctes

char DoEverything(
        int meaninglessParameterName1,
        char *meaninglessParameterName2,
        ....
        long double *meaninglessParameterName97)
        { return !NULL;}

Eclipse identifiera réellement la ligne avec le mauvais paramètre

8
Mawg says reinstate Monica

Eh bien, si vous en faites un objet JSON, vous pouvez ensuite envelopper les 97 (ou plus) dans cet objet et n'envoyer qu'un seul objet.

5
Mark Schultheiss

S'il s'agit de plus de 5 à 10 paramètres, puis créez un objet qui prend les paramètres à la place, il peut s'agir d'un ensemble de données typé, d'une structure ou autre.

Au lieu de :

Mywebservice.CreateUser(Firstname, LastName, Age,Sex, Haircolor,AmountOfFingers,AmountOfTeeht,Childrens,,,,,,,,,,,,,and so on)

Faire:

Dim MyUser as new UserObject
MyUser.Firstname="Stefan"
...and so on...
MyWebservice.CreateUser(UserObject)
3
Stefan

Dans ma propre expérience, j'ai trouvé que les signatures de méthode commencent à devenir confuses et difficiles à mémoriser avec plus de 5 ou 6 paramètres. Et une fois que vous avez dépassé les 10 paramètres, c'est tout simplement ridicule.

Ces paramètres doivent vraiment être combinés en un objet (ou un petit ensemble d'objets) qui contient toutes les données. Dans les services que j'utilise, chaque opération de service prend toujours un seul objet Request et renvoie un seul objet Response.

1
Kaleb Brasee

Eh bien, je suggère de surcharger la méthode pour que vous ayez des implémentations plus simples de la méthode. Cela peut être particulièrement utile si de nombreux paramètres changent rarement et peuvent être affectés par défaut. Cependant, si la mémoire est bonne, je ne pense pas que vous puissiez surcharger un appel de service Web (vous devez utiliser un nom de méthode distinct).

Une autre solution possible consiste à encapsuler les paramètres dans une sorte de classe de métadonnées dont le but est de conserver les paramètres. Cela simplifierait la signature de la méthode. Cependant, à certains égards, vous déchargez simplement le problème dans la classe de paramètres. Mais, si les paramètres peuvent être classés en thèmes, cette technique peut être employée en utilisant plusieurs classes de métadonnées, chacune qui serait incluse comme paramètre au service Web. Cela devrait simplifier les choses et vous aider à comprendre ce monstre.

Enfin, c'est difficile à dire sans aucun détail, mais il semble certainement que ce code est un candidat sérieux pour le refactoring. Je n'ai pas de règle stricte et rapide sur le nombre de paramètres pour une méthode autre que d'adopter le principe général de simplicité et de lisibilité.

0
Ed Chaparro

En ce qui concerne les services Web, je préfère gérer les paramètres comme un seul objet. Bien que votre contrat de données puisse changer, votre contrat de service ne changera pas. Cela rend vos services plus pérennes.

Pour tout le reste, je suis pour 3 paramètres et parfois aller jusqu'à 5.

0
John Laffoon