oop - control - dependency injection swift

¿Cuál es la verdadera diferencia entre "Inyección Bastarda" y "Inyección Pobre"?

Question

Del libro "Dependency Injection in .Net" sé que el gráfico de objetos debe crearse en la raíz de composición de la aplicación, lo cual tiene mucho sentido para mí cuando se usa un contenedor IoC.

En todas las aplicaciones que he visto cuando se hace un intento de usar DI, siempre hay dos constructores: uno con las dependencias como parámetros y el "predeterminado" sin parámetros que a su vez llama al otro "newing" todas las dependencias pero, en el libro mencionado anteriormente, esto se llama el "anti-patrón de Inyección Bastardo" y eso es lo que yo solía conocer como "Inyección de Pobre".

Ahora, teniendo en cuenta todo esto, diría que "Poor Man''s Injection" simplemente no usaría un contenedor de IoC y en su lugar codificaría todo el gráfico de objetos a mano en dicha raíz de composición .

Entonces mis preguntas son:

1. ¿Estoy entendiendo estos conceptos correctamente o estoy completamente fuera de la pista?
2. Si aún necesita registrar todas las dependencias en el contenedor IoC frente a codificarlas a mano en la misma raíz de composición, ¿cuál es el beneficio real de usar un contenedor IoC?
3. Si he entendido mal lo que realmente es la "Inyección de Pobre", ¿podría alguien aclararlo?

Gracias

Answer 1

Algunas notas a la parte 2) de la pregunta.

Si aún necesita registrar todas las dependencias en el contenedor IoC frente a codificarlas a mano en la misma raíz de composición, ¿cuál es el beneficio real de usar un contenedor IoC?

• Si tiene un árbol de dependencias (clasess que dependen de dependencias que dependen de otras dependencias, etc.): no puede hacer todas las "noticias" en una raíz de composición, porque actualiza las instancias en cada "inyección bastarda". constructor de cada clase, por lo que hay muchas "raíces de composición" extendidas a lo largo de su base de código

• Si tiene un árbol de dependencias, o no, usar un contenedor IoC le permitirá escribir algún código. Imagine que tiene 20 clases diferentes que dependen de la misma IDependency . Si usa un contenedor, puede proporcionar una configuración que le permita saber qué instancia usar para IDependency . Harás esto en un solo lugar, y el contenedor se encargará de proporcionar la instancia en todas las clases dependientes.

• El contenedor también puede controlar la duración del objeto, lo que ofrece otra ventaja.

Todo esto, aparte de las otras ventajas obvias proporcionadas por DI (capacidad de prueba, mantenimiento, descifrado de código, extensibilidad ...)

Answer 2

Cuando se trata de DI, hay un gran uso conflictivo de la terminología. El término DI de Poor Man no es una excepción. Para algunas personas, significa una cosa y para otras significa algo diferente.

Una de las cosas que quería hacer con el libro era proporcionar un lenguaje de patrones consistente para DI. Cuando se trataba de todos esos términos con un uso conflictivo, tenía dos opciones: inventar un término completamente nuevo o elegir el uso más frecuente (de acuerdo con mi juicio subjetivo).

En general, he preferido volver a utilizar la terminología existente en lugar de inventar un lenguaje de patrones completamente nuevo (y por lo tanto ajeno). Eso significa que en ciertos casos (como DI de Poor Man), puede tener una noción diferente de cuál es el nombre que la definición dada en el libro. Eso sucede a menudo con los libros de patrones.

Al menos, me parece tranquilizador que el libro haya hecho su trabajo de explicar exactamente tanto DI de Poor como Inyección de Bastardo, porque la interpretación dada en el PO es acertada.

En cuanto al beneficio real de un DI Container, lo referiré a esta respuesta: Argumentos en contra de la Inversión de contenedores de Control

PD 2018-04-13: Me gustaría señalar que hace años reconozco que el término DI de Poor Man hace un trabajo deficiente (sic!) De comunicar la esencia del principio, por lo que durante años, ahora , En cambio , lo he llamado Pure DI .