Cómo tratar con constructores en clases de datos grandes [duplicar]

7

Ahora, varias veces me he encontrado con situaciones en las que tienes algún tipo de clase de configuración que simplemente contiene una gran cantidad de datos. A menudo, estas clases simplemente no son válidas sin al menos la mayoría de los datos.

Sin embargo, un constructor como este:

public dataclass (int v1, int v2, int v3, int v4,
      string v5, double v6, string v7, int v8, 
      Internalclass v9, string v10,
      double v11, double v12, int v13, int v14)
{
   this.v1=v1;
   this.v2=v2;
   ...
   this.v14=v14; 
}

siente que no es una buena práctica de código. Ahora podría intentar agrupar algunas de estas variables pero a menudo estas variables solo tienen sentido en el contexto de la clase de datos. Entonces, ¿cuál es una buena manera de diseñar una clase de datos de este tipo?

    
pregunta Thijser 09.11.2015 - 13:10

3 respuestas

12

Está buscando el patrón de creación .

Esencialmente, es un objeto con definidores donde puede configurar los parámetros para la construcción y un método createResult() que creará el objeto que está buscando (o fallará si no fuera válido).

Puede usarlo para contener los valores predeterminados de las propiedades y agrupar algunas de ellas en un solo configurador.

DataClassBuilder builder = new DataClassBuilder();

builder.setV1(v1);
builder.setV3(v3);
builder.setV4(v4);
builder.setV5AndV6(v5, v6);
//...

DataClass data = builder.createResult();
    
respondido por el ratchet freak 09.11.2015 - 13:22
5

¿Se requieren todos esos parámetros en realidad ? Por "clase de datos", ¿te refieres a un Modelo de Dominio , Ver Modelo o Objeto de Transferencia de Datos ? Requerir una lista tan grande de argumentos para una simple "clase de datos" comienza a sentirse como un Code Smell que le dice a uno u otro:

  1. Esta clase está haciendo demasiado, y gran parte de su trabajo debe delegarse a otras clases que se pasan como una dependencia

  2. No todo es necesario. Los valores opcionales en las clases de datos no deben pasarse a través del constructor

Creo que la pregunta aquí no es "¿Cómo puedo manejar una gran lista de argumentos de constructores" y en cambio es "¿Cómo puedo refactorizar mi modelo de objetos para que no necesite dos docenas de parámetros para un constructor?"

El patrón del generador "solucionará" su problema, pero creo que está poniendo una venda en un problema más grande que requiere una solución diferente.

    
respondido por el Greg Burghardt 09.11.2015 - 14:36
0

Si sus parámetros son opcionales, ¡el patrón Builder podría ser realmente útil! Sin embargo, el patrón de construcción puede ser un desastre a veces. Si usa Builder en muchos lugares, cuando agregue un nuevo parámetro, deberá asegurarse de no olvidar agregarlo en todos los lugares porque no tendrá una verificación de tiempo de compilación.

Si los parámetros no son opcionales, necesitarás verificar que todo se haya configurado en el momento para llamar al método Build .

Me gustaría proponer otra solución, el Presentar Objeto de Parámetro .

La idea es agrupar tus parámetros (si es posible) por alguna lógica. Luego, tendría menos parámetros en este constructor y tal vez 3-4 más "clases de parámetros". Podría argumentar que esto mueve el problema a otra parte, pero le brinda más flexibilidad sobre cómo crear estos objetos de parámetros.

Tal vez uno de los "objetos de parámetros" se puede crear a través de una fábrica codificada, el otro se puede recuperar de un archivo de configuración, etc.

¡De esta manera creará una mejor separación de preocupaciones!

    
respondido por el IEatBagels 09.11.2015 - 17:44

Lea otras preguntas en las etiquetas