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?
fuente
Respuestas:
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 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 gustaencapsulando tres parámetros "X, Y, Z" en un parámetro "posición de tipo
Point3D, oparámetros de encapsulación "startDate, endDate" en un objeto
DateIntervaloencapsulando parámetros
documentTitle, documentText, authoren un objeto queDocumentagrupa estos parámetrosSi 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.
fuente
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.
fuente