Tengo una clase que necesita 12 parámetros para pasar a su constructor. Entonces creo que hay algo mal con el diseño de esta clase.Número de parámetros para un constructor
me gustaría preguntar si hay algún patrón de diseño o una colección general de las normas en relación con el diseño de una clase, especialmente su constructor.
12 parámetros definitivamente me parecen demasiado. Opciones para reducir su número es:
Introduce Parameter Object mediante la agrupación de los parámetros relacionados lógicamente en un objeto y que pasa a ese objeto en lugar de los parámetros individuales.
Introduzca un Builder (opcionalmente con method chaining). Esto no reduce la lista de parámetros real, pero hace que el código sea más legible, y es especialmente útil si tiene varios escenarios de creación diferentes con parámetros variables. Así que en lugar de
MyClass someObject = new MyClass(aFoo, aBar, aBlah, aBaz, aBorp, aFlirp,
andAGoo);
MyClass anotherObject = new MyClass(aFoo, null, null, aBaz, null, null,
andAGoo);
puede tener
MyClass someObject = new MyClassBuilder().withFoo(aFoo).withBar(aBar)
.withBlah(aBlah).withBaz(aBaz).withBorp(aBorp).withFlirp(aFlirp)
.withGoo(aGoo).build();
MyClass anotherObject = new MyClassBuilder().withFoo(aFoo).withBaz(aBaz)
.withGoo(aGoo).build();
(quizás debería haber empezado con este ;-) Analizar los parámetros - es todo de ellos realmente se necesita en el constructor (es decir obligatorio)? Si un parámetro es opcional, puede establecerlo a través de su configurador regular en lugar del constructor.
+1 para el enfoque del constructor, es una solución elegante – stijn
Definitivamente haré 3. antes de siquiera intentar 1. o 2. :) –
Creo que esto puede ser aceptable cuando se utiliza el patrón de estado, por ejemplo. Sin embargo, ¿podría sugerir pasar el objeto (si corresponde) de donde provienen esos parámetros? ¿Y luego en el constructor cargar los datos desde allí?
si es posible es posible agrupar los parámetros de clases y pasar sus instancias al constructor.
Este es el enfoque adoptado, por ejemplo. por las funciones API de Win32. –
Si su función toma once parámetros, es probable que haya olvidado una más
Me encanta esta frase, ya que lo resume todo: Bad diseño requiere de un mal diseño.
Tomé esto del libro C++ Estándares de codificación: 101 Reglas, pautas y mejores prácticas por Herb Sutter, Andrei Alexandrescu.
Editar: La cita directa es Si tiene un procedimiento con diez parámetros, probablemente haya perdido alguno. Es en sí mismo a quote from Alan Perlis.
Funciones con tantos parámetros son un Síntoma de un mal diseño. Una de las posibilidades es tratar de encapsular parte de estos parámetros en una entidad/clase que tiene un objetivo definido. (No es una clase de basura que enumeraría todos los parámetros sin una estructura significativa).
Nunca olvidar el Single Responsibility Principle Como consecuencia, las clases siguen siendo limitados en tamaño, y como consecuencia, limitados en número de parametros miembros, y por lo tanto limitado en el tamaño de los parámetros necesarios para sus constructores.Como dice uno de los comentarios a continuación, la clase con tantos parámetros de constructor puede manejar demasiados detalles inútiles independientemente de su objetivo principal.
Un vistazo a esto se aconseja también: How many parameters are too many?
12 parámetros, algo que es muy probablemente mal con el diseño.
¿Qué se hace con los parámetros?
La alternativa es que se trata de parámetros para una construcción de bajo nivel y rendimiento crítico, en cuyo caso el diseño solo tiene que recuperar el asiento, pero eso rara vez es el caso.
Un constructor que toma 12 parámetros es un olor a código. Lo más probable es que tu clase esté tratando de hacer demasiado. –
Eche un vistazo a esta pregunta: [how-many-variables-should-a-constructor-have] (http://stackoverflow.com/questions/1434498/how-many-variables-should-a-constructor-have) Aunque el OP usa C#, las respuestas son aplicables a C++. – Tony