Cuándo utilizar la inyección de dependencia? Cuando no?

Question

Por lo que entiendo, el trade-off aquí es una cuestión de complejidad añadida. ¿Tal vez?

Parece que (¿siempre?) Más desacoplado para usar Inyección de Dependencia, pero más simple (para muchas personas) sin él.

Por lo que entiendo acerca de todo en la vida, nada es absoluto, y hay un momento y lugar para todo. Estoy tratando de entender las concesiones aquí.

Answer 1

Dependencia Si la inyección se realiza correctamente (¿efectivamente?), Ciertamente desacopla sus objetos. En mi opinión, el área donde se realiza más este beneficio es cuando se usan objetos simulados o de talón en las pruebas de su unidad. Con bastante frecuencia, esto significa que se realizarán menos pruebas unitarias en cada prueba individual, lo que las simplificará. Esta promoción de pruebas unitarias efectivas a menudo trae sus propios beneficios adicionales.

No diría necesariamente que DI agrega complejidad porque si el diseño de un sistema es poco elegante será complejo si usa DI o no. Sin embargo, puede agregar una curva de aprendizaje adicional si usa un marco DI por primera vez, por ejemplo, el marco Spring.

Answer 2

Use Dependency Injection cuando desee crear implementaciones alternativas de un tipo de servicio determinado. El ejemplo canónico de esto es sustituir un objeto simulado en lugar de un proveedor de servicios con fines de prueba.

Por ejemplo, Dependency Injection le permite usar una base de datos "real" o una base de datos "falsa" que imita el comportamiento de la base de datos real. En ambos casos, la dependencia que se "inyecta" tiene la misma interfaz, pero puede cambiar la implementación.

Answer 3

En la práctica, los diseños basados ​​en inyección de dependencia son mucho más fáciles de manejar porque hay más control, menos acoplamiento entre clases, más flexibilidad con la implementación y permite un uso más amplio de las clases existentes Una aplicación.

Depende de cuán claramente definidas o intuitivas sean las dependencias también. Viniendo de un fondo nativo de C++, encontré partes en .NET donde las dependencias eran claramente obvias y proporcionaban mucha flexibilidad, pero otras áreas que simplemente no entendía en absoluto y no podían comprender de inmediato los requisitos para usar un determinado fragmento de código u objeto, debido a una variedad de factores que incluyen el nombre de la clase y mi conocimiento del sistema.

Digo, si va a diseñar su código con inyección de dependencia en mente, intente hacer que las dependencias sean lo más claras e intuitivas posible.

Esa es mi idea de todos modos.

Answer 4

Existe un amplio espectro cubierto por la "inyección de dependencia", que pasa de los parámetros del constructor a un marco configurado por XML. Un medio feliz que recientemente "descubrí" cubre muchos de los casos "falsos" sin necesidad de un marco real. Es un poco subversivo, pero es mucho más fácil trabajar con él en casos aislados.

Usted anula un método de fábrica dentro de su código principal para ejecutar pruebas con un servicio falso. Básicamente es una compensación entre el abuso de herencia (con este método) y el abuso de configuración (con marcos). De cualquier forma, es "inyección de dependencia", o como en el mundo real nos gusta llamarlo, parametrización.

Código principal:

public class A { 
    // ... 
    private service; 

    protected Service getService() { 
     return new RealService(); 
    } 

    public A() { 
     service = getService(); 
    } 
    // ... 
} 

Código de ensayo:

public class Test { 
    void test() { 
     final Service fakeService = new FakeService(); 
     A thingToTest = new A() { 
      protected Service getService() { return fakeService; } 
     } 
     thingToTest.doOneThing(); 
     // ... 
    } 
}