2012-02-09 12 views
5

En mi empleador, es una política que usemos listas de inicialización en el constructor porque es más eficiente.¿Desventaja a la lista de inicialización grande?

Sin embargo, estoy desarrollando una clase que tiene 45 miembros de datos que requieren inicialización. Según la política, esto debería hacerse en una lista de inicialización en el constructor.

Aparte de la legibilidad, ¿cuál sería la desventaja de una gran lista de inicialización?

+1

¿Aparte de la legibilidad? No puedo pensar en nada, además del potencial de error. –

+7

Sugerencia: si tiene 45 atributos de miembro, es posible que no esté dividiendo las responsabilidades de manera apropiada. –

Respuesta

8

Puede formatear una lista de inicializadores de miembros sobre múltiples líneas de origen físico, por lo que no tiene por qué ser un problema de legibilidad.

El problema más grande es obviamente el hecho de que tiene clases con 45 miembros de datos. Nada va a hacer que trabajar con tales clases sea particularmente fácil.


AClass::AClass(type1 val1 
       , type2 val2 
       // ... 
       , type45 val45) 
: mem1(val1) 
, mem2(val2) 
// ... 
, mem45(val45) 
{ 
} 

argumento no es menos fácil de leer que:

AClass::AClass(type1 val1 
       , type2 val2 
       // ... 
       , type45 val45) 
{ 
    mem1 = val1; 
    mem2 = val2; 
    // ... 
    mem45 = val45; 
} 
8

creo que valdría la pena dar un paso atrás para entender por qué su clase tiene 45 miembros de datos. Esto generalmente es una señal de que su clase está haciendo demasiadas cosas y tiene demasiadas responsabilidades separadas que harán que esta clase sea muy difícil de mantener con el tiempo.

Parece que puede necesitar dividir su clase en piezas funcionales separadas y tener la clase 'controladora' delegada en subclases. Esto disminuirá drásticamente la complejidad de tu código.

-1

Algunas optimizaciones fallarán, sospecho que la incorporación de dicho constructor no funcionará.

De cualquier forma: 45 Los miembros de los datos suenan mucho. ¿Puedes agruparlos para objetos agregados?

+1

¿por qué fallarían con una lista de inicializadores y no sin una lista de inicializadores (donde copiarías esas inicializaciones al cuerpo)? – KillianDS

3

Parece bien conocido anti-patrón objeto de Dios. citación wiki:

In object-oriented programming, a God object is an object that knows too much or does too much.

Por favor, encontrar una manera de reconsiderar su diseño a los miembros del grupo del objeto a Dios en estructuras y objetos más pequeños con sus propios procedimientos de inicialización.

lo tanto una respuesta a la pregunta "¿cuál sería la desventaja de una lista de inicialización grande? (En comparación con una pequeña)" podría ser "Es grande, por lo que posiblemente se trate de un mal estilo."

Respondiendo a la pregunta "¿cuál sería la desventaja de una lista de inicialización grande?" (Comparando con un cuerpo constructor grande) "podría ser" ninguno ", porque la inicialización debe hacerse mejor en la lista, no en el cuerpo, pero la legibilidad y el costo de mantenimiento son los mismos (para mí).

+1

¿Qué parte de esto responde a la pregunta sobre las desventajas de las grandes listas de inicialización? –

+0

La parte que dice "si tiene grandes listas de inicialización, entonces * ese * es un problema". –

Cuestiones relacionadas