Parfois (rarement), il semble que la meilleure voie consiste à créer une fonction qui prend une quantité décente de paramètres.
L'utilisation de plusieurs paramètres est souvent un indicateur clair que vous violez le SRP avec cette méthode. Une méthode nécessitant de nombreux paramètres a peu de chance de faire une seule chose. L'excétion peut être une fonction mathématique ou une méthode de configuration, où plusieurs paramètres en tant que tels sont nécessaires. J'éviterais plusieurs paramètres comme le diable évite l'eau bénite. Plus vous utilisez de paramètres dans une méthode, plus il y a de chances que la méthode soit (trop) complexe; plus la complexité signifie: plus difficile à maintenir et moins souhaitable.
Cependant, quand je le fais, j'ai l'impression de choisir souvent l'ordre des paramètres au hasard. Je vais généralement par "ordre d'importance", avec le paramètre le plus important en premier.
En principe, vous choisissez au hasard . Bien sûr, vous pourriez penser que le paramètre A est plus pertinent que le paramètre B ; mais cela pourrait ne pas être le cas pour les utilisateurs de votre API, qui pensent que B est le paramètre le plus pertinent. Donc, même si vous avez été attentif dans le choix de la commande, cela pourrait sembler aléatoire pour d'autres .
Y a-t-il une meilleure manière de faire cela? Existe-t-il une "bonne pratique" pour classer les paramètres qui améliore la clarté?
Il y a plusieurs issues:
a) Le cas trivial: N'utilisez pas plus d'un paramètre.
b) Comme vous n'avez pas précisé la langue que vous avez choisie, il est possible que vous choisissiez une langue avec des paramètres nommés . C'est un bon sucre syntaxique qui vous permet de desserrer la signification de l'ordre des paramètres:fn(name:"John Doe", age:36)
Toutes les langues ne permettent pas de telles subtilités. Alors quoi alors?
c) Vous pouvez utiliser un dictionnaire / tableau de hachage / tableau associatif en tant que paramètre: par exemple, Javascript autoriserait ce qui suit: fn({"name":"John Doe", age:36})
ce qui n'est pas loin de (b).
d) Bien sûr, si vous travaillez avec un langage typé statiquement , tel que Java. vous pouvez utiliser une table de hachage , mais vous perdriez des informations de type (par exemple lorsque vous travaillez avec HashMap<String, Object>
) lorsque les paramètres ont des types différents (et doivent être transtypés).
La prochaine étape logique serait de passer un Object
(si vous utilisez Java) avec les propriétés appropriées ou quelque chose de plus léger comme une structure (si vous écrivez par exemple C # ou C / C ++).
Règle de base:
1) Meilleur cas - votre méthode n'a besoin d' aucun paramètre
2) Bon cas - votre méthode nécessite un paramètre
3) Cas tolérable - votre méthode nécessite deux paramètres
4) Tous les autres cas devraient être refactorisés
MessageBox.Show
. Regardez dans cela aussi.