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

Question

Lors du débogage d'un web-service client code aujourd'hui (en Java, avec jax-ws), j'ai couru à travers un web-service méthode avec l'esprit de soufflage montant de 97 paramètres!

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

• assistance de code/hover n'est pas à l'échelle. Je suis à l'aide d'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 à partir d'un xml précédente capture, et il était pratiquement impossible de se souvenir "où suis-je" - quand j'ai eu le curseur se trouve après la virgule et avant de taper une certaine valeur, j'ai souvent eu le type de données de mal - j'ai tapé un Entier au lieu d'une Chaîne de caractères et vice versa.
• Même après que j'ai écrit à tous les paramètres, j'avais encore quelques erreurs et que la signature n'a pas de match. Malheureusement Eclipse marques de l'ensemble de la ligne en rouge comme ayant une erreur, afin de trouver où l'erreur a été pris encore plus de temps :(

Donc, cela m'a fait penser, que pensez-vous est le maximum sane nombre de paramètres d'une méthode? Et si vous pouviez changer cette web-service de signature, comment pensez vous que cela peut-il être amélioré?

Answer 1

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 le Code Propre recommande à 3 max.

Il y a plusieurs refactorings de réduire le nombre de paramètres de la méthode (voir le Travail de manière Efficace avec le Code existant, par Michael Plumes pour plus de détails). Ceux-ci viennent à mon esprit:

• encapsuler plusieurs paramètres dans un seul objet (par exemple, au lieu de String surName, String firstName, String streetAddress, String phoneNumber passer un Person objet contenant ces champs)
• passer des paramètres au constructeur ou à d'autres appels de méthode avant l'invocation de cette méthode

Answer 2

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

Answer 3

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

Bonne pratique généralement le conseille à propos de max. de six à huit. Bien sûr, ymmv, et il y a peut être une raison valable, de temps à autre, pour une neuvième. Mais 97??!!

Quelques pensées ... sont simplement ces données, ou sont les décisions soient fondées sur leurs valeurs?

Si un grand nombre de/la plus grande incidence sur les flux de contrôle, vous avez presque désuète (même compréhensible, ou testables) "conception" (pour de petites valeurs de la "conception").

Si elles sont tout simplement des données, peuvent-ils être regroupés dans des structures et pointeurs ot ces structures passé?

Avez vous de la documentation sur la conception? Peut-être que d'expliquer ce qui se passe.

Oh, et, "le Danger, will Robinson" - quelqu'un qui va passer de 97 paramètres ouvertement pourrait aussi passer n'importe quel nombre - pas alors, évidemment - comme des variables globales.

P. s ne savent pas comment Eclipse fonctionne sur Java, mais avec le C/C++, si vous mettez le paramaeters sur des lignes séparées

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

L'éclipse sera réellement identifier la ligne avec le mauvais paramètre

Answer 4

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