A veces (rara vez), parece que crear una función que tome una cantidad decente de parámetros es la mejor ruta.
El uso de varios parámetros suele ser un indicador claro de que viola el SRP en este método. Es poco probable que un método que necesite muchos parámetros haga solo una cosa. Excpetion puede ser una función matemática o un método de configuración, donde de hecho se necesitan varios parámetros como tales. Evitaría múltiples parámetros ya que el diablo evita el agua bendita. Cuantos más parámetros utilice dentro de un método, mayor será la posibilidad de que el método sea (también) complejo; más complejidad significa: más difícil de mantener y eso es menos deseable.
Sin embargo, cuando lo hago, siento que a menudo estoy eligiendo el orden de los parámetros al azar. Normalmente voy por "orden de importancia", con el parámetro más importante primero.
En principio, está seleccionando al azar . Por supuesto, puede pensar que el parámetro A es más relevante que el parámetro B ; pero ese podría no ser el caso para los usuarios de su API, quienes piensan que B es el parámetro más relevante. Así que incluso si estuviera atento a la hora de elegir el pedido, para otros podría parecer aleatorio .
¿Hay una mejor manera de hacer esto? ¿Existe una forma de "mejores prácticas" para ordenar parámetros que mejore la claridad?
Hay varias maneras de salir:
a) El caso trivial: no utilice más de un parámetro.
b) Como no especificó, qué idioma ha elegido, existe la posibilidad de que elija un idioma con parámetros con nombre .
Esto es bueno, azúcar sintáctica , que le permite aflojar el significado del orden de los parámetros: fn(name:"John Doe", age:36)
No todos los idiomas permiten tales detalles. ¿Entonces, qué?
c) Podría usar un Dictionary / Hashmap / Associative Array como parámetro:
p.ej. Javascript permitiría lo siguiente: fn({"name":"John Doe", age:36})
que no está muy lejos de (b).
d) Por supuesto, si trabaja con un lenguaje estático como Java. podría usar un Hashmap , pero perdería la información de tipo (por ejemplo, cuando trabaje con HashMap<String, Object>
) cuando los parámetros tengan diferentes tipos (y deben ser emitidos).
El siguiente paso lógico sería pasar un Object
(si está usando Java) con las propiedades apropiadas o algo más liviano como una struct (si escribe, por ejemplo, C # o C / C ++) .
Regla de oro:
1) Mejor caso: su método necesita el parámetro no en absoluto
2) Buen caso: su método necesita un parámetro
3) Caso tolerable: su método necesita dos parámetros
4) Todos los demás casos deben ser refactorizados