¿Es "demasiados parámetros" un problema visual o lógico?

8

de acuerdo con ¿Existen pautas sobre cuántos parámetros debe aceptar una función? , un método no debe tener demasiados parámetros. Sin embargo, algunas respuestas sugieren que este problema puede resolverse mediante un patrón de generador:

Builder b=new Builder();
b.setParm1("a");
b.setParm2("b");
.
.
.
Obj obj=b.createObj();

o encapsular parámetros en un solo objeto.

ObjectParam op=new ObjectParam();
op.param1="a";
op.param2="b";
.
.
.
obj.f(op);

Pero dudo si resuelve el problema, porque creo que los métodos simplemente alinean los parámetros de una mejor manera (es decir, de horizontal a vertical), pero no cambia la naturaleza de que las tareas dependen de demasiados parámetros. Y si quiero que la cadena de parámetros tenga una mejor apariencia, puedo usar una nueva línea para cada parámetro como este:

https://softwareengineering.stackexchange.com/a/331680/248528

entonces mi pregunta es, ¿son "demasiados parámetros" un problema visual (difícil de leer una sola línea larga de código), o un problema lógico (la naturaleza de la tarea depende de demasiados parámetros y las necesidades se descomponen)? Si se trata más de un problema visual, ¿una nueva línea para cada parámetro resuelve el problema?

coding-style parameters

— ocomfd
fuente

3

OMI demasiados parámetros es más un olor a código para un problema lógico. Demasiados parámetros implican demasiadas dependencias => el método posiblemente está haciendo demasiadas cosas. Por supuesto, hay situaciones en las que muchos parámetros pueden estar bien desde el punto de vista de SRP (por ejemplo, ha optado por pasar una larga lista de parámetros en lugar de usar una lista), pero indica otros problemas (elección incorrecta / ausencia de estructura de datos )

— peladillas el

24

Es ante todo un problema lógico (que a menudo también viene con problemas visuales). La solución incorrecta a esto es tratar solo de mejorar el problema visual

encapsular parámetros en un solo objeto [...] simplemente alinear los parámetros de una mejor manera (es decir, de horizontal a vertical)

Encapsular parámetros en un objeto no significa poner cinco parámetros en un contenedor arbitrario con algún nombre sin sentido como ObjectParam. En cambio, encapsular un grupo de parámetros en un objeto debería crear una nueva abstracción (o reutilizar una existente). Me gusta

encapsulando tres parámetros "X, Y, Z" en un parámetro "posición de tipo Point3D, o
parámetros de encapsulación "startDate, endDate" en un objeto DateIntervalo
encapsulando parámetros documentTitle, documentText, authoren un objeto que Documentagrupa estos parámetros

Si el método en juego tiene muchos parámetros no relacionados, no puede encontrar un buen nombre de agrupación, entonces probablemente tenga demasiados parámetros y demasiadas responsabilidades.

— Doc Brown
fuente

66

Poeple también trata de solucionar el problema visual, moviendo los parámetros de la función al nivel de clase, haciéndolo menos abarrotado, pero menos obvio y con la misma complejidad lógica. O peor aún, mueva el parámetro al estado global, porque no desea pasarlo. Sucede ...

— Chris Wohlert

@ChrisWohlert Sí, hay personas que creen que seguir muchas "reglas" mejora su código, porque no saben lo que están haciendo. Los desarrolladores competentes saben cuándo ignorar mejor las reglas que crear kludges solo para seguir la regla.

— Ralf Kleberhoff

Una lista de parámetros y un "objeto" de parámetros son casi lo mismo, en términos de carga mental y posiblemente incluso de sintaxis. Esta es una buena respuesta.

— Frank Hileman

1

Un método que toma muchos parámetros es, en esencia, un paso en la dirección opuesta a la convención sobre el enfoque de configuración , que se centra en simplificar tales llamadas sin perder la capacidad de cambiar los valores según sea necesario mediante el uso de valores predeterminados sensibles .

En otras palabras, claramente no desea perder flexibilidad, pero seguramente no necesita que todos los parámetros se pasen dinámicamente. Es probable que muchos parámetros sean fijos / estáticos. Tome un programa zip como ejemplo. Sí, quizás desee cambiar el algoritmo de compresión, el nivel de compresión, el número de núcleos de CPU para dedicar a la tarea, ... lo que sea. El punto es que nadie quiere especificar todos estos parámetros cada vez que necesite crear un archivo zip, reduciendo efectivamente una llamada al proporcionar los elementos esenciales básicos (es decir, el nombre del archivo zip de destino, los archivos para agregar al archivo zip).

Las razones por las que usaría la convención sobre el enfoque de configuración son las mismas razones por las que no debería tener métodos que requieran muchos parámetros. En resumen, la simplicidad es buena.

— Neil
fuente