Tengo que decir que, en mi opinión, toda la noción de inyección de dependencia está sobrevaluada.
DI es el equivalente moderno de los valores globales. Las cosas que está inyectando son singletons globales y objetos de código puro, de lo contrario, no podría inyectarlos. La mayoría de los usos de DI son forzados para usar una biblioteca determinada (JPA, Spring Data, etc.). En su mayor parte, DI proporciona el ambiente perfecto para nutrir y cultivar espaguetis.
Honestamente, la forma más fácil de probar una clase es asegurarse de que todas las dependencias se creen en un método que pueda ser anulado. Luego cree una clase de prueba derivada de la clase real y anule ese método.
Luego, crea una instancia de la clase Prueba y prueba todos sus métodos. Esto no será claro para algunos de ustedes: los métodos que está probando son los que pertenecen a la clase bajo prueba. Y todas estas pruebas de métodos se realizan en un solo archivo de clase: la clase de prueba unitaria asociada con la clase bajo prueba. Aquí no hay sobrecarga, así es como funcionan las pruebas unitarias.
En el código, este concepto se ve así ...
class ClassUnderTest {
protected final ADependency;
protected final AnotherDependency;
// Call from a factory or use an initializer
public void initializeDependencies() {
aDependency = new ADependency();
anotherDependency = new AnotherDependency();
}
}
class TestClassUnderTest extends ClassUnderTest {
@Override
public void initializeDependencies() {
aDependency = new MockitoObject();
anotherDependency = new MockitoObject();
}
// Unit tests go here...
// Unit tests call base class methods
}
El resultado es exactamente equivalente al uso de DI, es decir, el ClassUnderTest está configurado para la prueba.
Las únicas diferencias son que este código es completamente conciso, completamente encapsulado, fácil de codificar, más fácil de entender, más rápido, usa menos memoria, no requiere una configuración alternativa, no requiere ningún marco, nunca será la causa de un seguimiento de pila de 4 páginas (WTF!) que incluye exactamente CERO (0) clases que usted escribió, y es completamente obvio para cualquiera con el más mínimo conocimiento de OO, desde principiante hasta Guru (pensaría, pero estaría equivocado).
Dicho esto, por supuesto que no podemos usarlo, es demasiado obvio y no está lo suficientemente a la moda.
Al final del día, sin embargo, mi mayor preocupación con DI es la de los proyectos que he visto fracasar miserablemente, todos ellos han sido bases de código masivas donde DI era el pegamento que mantenía todo unido. DI no es una arquitectura, en realidad solo es relevante en un puñado de situaciones, la mayoría de las cuales son forzadas para usar otra biblioteca (JPA, Spring Data, etc.). En su mayor parte, en una base de código bien diseñada, la mayoría de los usos de DI se producirían en un nivel por debajo del lugar donde se realizan sus actividades de desarrollo diarias.