¿El tamaño del constructor importa si estás mediante la Inversión de Control?

Question

Así que tengo tal vez 10 objetos de cada uno de los cuales ha 1-3 dependencias (que creo que es aceptar tan lejos como el acoplamiento flexible se refiere), pero también algunas opciones de configuración que pueden ser utilizados para definir el comportamiento (tiempo de espera, el tamaño de la ventana, etc).

Ahora, antes de que empecé a usar un contenedor de Inversión de Control habría creado una fábrica y tal vez incluso un simple ObjectSettings objeto para cada uno de los objetos que se requiere más de 1 ajuste para mantener el tamaño del constructor a la recomendada "de menos de 4" tamaño del parámetro.Ahora estoy usando un contenedor de inversión de control y yo no veo mucho de un punto a ella.Seguro que yo podría ser un constructor con 7 parámetros, pero a quién le importa?Todo ser llenado por el Coi de todos modos.

Me estoy perdiendo algo aquí, o es básicamente correcto?

Answer 1

La relación entre la clase de la complejidad y el tamaño de la Coi constructor no se me ocurrió antes de leer esta pregunta, pero mi análisis a continuación sugiere que muchos de los argumentos que en el Coi constructor es un código de olor a tener en cuenta al utilizar Coi.Tener una meta de seguir un breve argumento de constructor de lista le ayudará a mantener las clases de simple.El siguiente principio de responsabilidad único le guiará hacia este objetivo.

Yo trabajo en un sistema que tiene actualmente 122 clases que se crea una instancia utilizando el Spring.NET marco.Todas las relaciones entre estas clases en los constructores.Es cierto que el sistema tiene su parte justa de menos que perfecto el código en el que me he roto un par de reglas.(Pero, hey, nuestros fracasos son oportunidades para aprender!)

Los constructores de las clases tienen un número variable de argumentos, que me muestran en la siguiente tabla.

Number of constructor arguments    Number of classes
           0                             57
           1                             19
           2                             25
           3                              9
           4                              3
           5                              1
           6                              3
           7                              2
           8                              2

Las clases con cero argumentos son de hormigón de la estrategia de las clases o cursos que respondan a los eventos mediante el envío de datos a sistemas externos.

Aquellos con 5 o 6 argumentos son algo poco elegante y podría utilizar algo de refactorización para simplificar ellos.

Las cuatro clases con 7 o 8 argumentos son excelentes ejemplos de Dios objetos.Deben ser divididos, y cada uno ya está en mi lista de problemas de manchas en el sistema.

El resto de las clases (de 1 a 4 argumentos) son (en su mayoría) de diseño simple, fácil de entender, y de acuerdo con el principio de responsabilidad único.

Answer 2

La necesidad de muchas dependencias (tal vez más de 8) podría ser indicativo de un defecto de diseño, pero en general yo creo que no hay problema, siempre y cuando el diseño es coherente.

También, considere el uso de un localizador de servicios o estática de la puerta de enlace para las cuestiones de infraestructura, tales como el registro y la autorización, en lugar de abarrotar el constructor de argumentos.

EDITAR:8 probablemente es demasiado, pero pensé que no tendría que ser el extraño caso para él.Después de mirar Lee el post estoy de acuerdo, 1-4 generalmente es bueno.

Answer 3

El g'day George,

En primer lugar, ¿cuáles son las dependencias entre los objetos?

Un montón de "isa" de las relaciones?Un montón de "hasa" relaciones?

Un montón de fan-in?O fan-out?

George respuesta:"tiene-un en su mayoría, han estado tratando de seguir la composición a lo largo de la herencia consejos...¿por qué importa aunque?"

Como es en su mayoría "hasa" usted debería estar bien.

Mejor asegurarse de que su construcción (y destrucción) de los componentes se realiza correctamente, aunque para evitar pérdidas de memoria.

Y, si esto es en C++, asegúrese de usar los destructores virtuales?

Answer 4

Esta es una pregunta difícil, y por qué estoy a favor de un enfoque híbrido donde las propiedades apropiadas son mutables y sólo inmutable propiedades y dependencias necesarias sin un valor predeterminado útil son parte del constructor.Algunas clases están construidos con los elementos esenciales, ajustado si es necesario a través de incubadoras.

Answer 5

Todo depende de qué tipo de contenedor en el que se han utilizado para hacer el COI y lo acerca al contenedor si se utiliza anotaciones o el archivo de configuración para saturar el objeto a ser instiantiated.Además, si los parámetros del constructor simplemente son tipos de datos simples entonces no es realmente un gran problema;sin embargo, si usted no es de los tipos primitivos, a continuación, en mi opinión, puede utilizar la Propiedad basada DI en lugar de consutructor basado DI.