Un patrón de diseño para constructores

Question

He sido cuestionado por un problema de diseño que trataré de describir a continuación.

Supongamos que una clase, llámala A, tiene un constructor con un conjunto de parámetros. Dado que es agotador y sucio escribir todos esos parámetros en cada instanciación, he escrito otra clase, llamémosla StyleSheetA, que encapsula todos esos parámetros y es el único parámetro para el constructor de A. De esta manera, puedo preparar algunos valores predeterminados Las plantillas StyleSheetA se usarán más adelante y, si es necesario, puedo modificarlas.

Y en este punto, necesito extender A. Supongamos que B extiende A. B tendrá su propia hoja de estilo, concretamente StyleSheetB. Creo que será apropiado que StyleSheetB extienda StyleSheetA, así que con un parámetro de hoja de estilo, el constructor de B también puede construir su super clase A. Pero tengo miedo de la posibilidad de que este diseño tenga fallas. Por ejemplo, ¿qué sucede si decido agregar un getter/setter para la hoja de estilo? ¿Hay alguna forma novedosa de manejar todas estas situaciones? ¿Estoy en el camino equivocado? Para aquellos que están confundidos, adjunto un cierto código aquí:

    class A 
    { 
     StyleSheetA ss; 

     A(StyleSheetA ss) 
     { 
      this.ss = ss; 
      // Do some stuff with ingredients of styleSheet 
     } 
    } 
    class StyleSheetA 
    { 
     int n1; 
     int n2; 
     // : 
     // : 
     int n100; 
    } 

    class B extends A 
    { 
     B(StyleSheetB ss) 
     { 
      super(ss); 
      // Do some stuff with ingredients of styleSheet 
     } 
    } 
    class StyleSheetB extends StyleSheetA 
    { 
     int n101; 
     int n102; 
     // : 
     // : 
     int n200; 
    } 

Gracias por cualquier ayuda o sugerencias, también cualquiera de sus críticos se apreciará.

Editar: Estoy desarrollando en java me por lo que no hay soporte para genéricos.

Answer 1

¿Ha considerado utilizar un contenedor IoC, como StructureMap, para gestionar sus dependencias de constructor? Eso podría hacer mucho de esto más fácil.

Answer 2

Me parece que solo está cambiando el problema de tener demasiados parámetros de la clase A a la clase StyleSheetA.

Para ilustrar mi punto, piensa en esta pregunta: ¿Cómo crearías una instancia de StyleSheetA? Probablemente usando un constructor que acepte todos estos parámetros, de todos modos. El único beneficio que le puede brindar este diseño es si tiene un mismo conjunto de valores de parámetros encapsulados por un objeto de StyleSheetA que podrá reutilizar entre varias instancias de A. Si es así, tenga en cuenta que, aunque tendría instancias diferentes de A, compartirían los mismos parámetros, por lo que no es una buena opción.

Lo que podría recomendar es tratar de refactorizar su clase A sí mismo. Intenta dividirlo en clases más pequeñas. Si nesseccary, intenta crear subclases para evitar ramas condicionales, etc.

Ahora, no sé cómo es tu clase A, pero tal vez si lo haces tendrás varias clases, cada una con su propio conjunto de parámetros Y si alguno de los parámetros es un discriminador (lo que significa que determina la clase "tipo"), usted podrá deshacerse de él, simplemente utilizando subclases, y confiando en el sistema de tipo incorporado para hacerlo.

Answer 3

pensamientos A en el getter y setter tema:

El constructor de 'B' implica que los parámetros adicionales (N101 +) son necesarios para el funcionamiento de la clase. Si solo ampliara la clase con una lista de parámetros completa, tendría getters y setters para n101 ... n200 en B y n1 ... n100 en A. Esto sugiere que tal vez no tenga StylesheetB extienda StylesheetA, sino que tenga el constructor a la clase B sea B(StyleSheetA,StyleSheetB), de esta manera puede tener un setter en la clase A para sus parámetros, tener eso heredado y también poner uno en B para StylesheetB.