He visto varios recomendar el uso de contenedores IoC en el código. La motivación es simple. Tome el siguiente código inyectado de dependencia:
class UnitUnderTest
{
std::auto_ptr<Dependency> d_;
public:
UnitUnderTest(
std::auto_ptr<Dependency> d = std::auto_ptr<Dependency>(new ConcreteDependency)
) : d_(d)
{
}
};
TEST(UnitUnderTest, Example)
{
std::auto_ptr<Dependency> dep(new MockDependency);
UnitUnderTest uut(dep);
//Test here
}
Dentro:
class UnitUnderTest
{
std::auto_ptr<Dependency> d_;
public:
UnitUnderTest()
{
d_.reset(static_cast<Dependency *>(IocContainer::Get("Dependency")));
}
};
TEST(UnitUnderTest, Example)
{
UnitUnderTest uut;
//Test here
}
//Config for IOC container normally
<Dependency>ConcreteDependency</Dependency>
//Config for IOC container for testing
<Dependency>MockDependency</Dependency>
(Lo anterior es un ejemplo hipotético de C ++, por supuesto)
Si bien estoy de acuerdo en que esto simplifica la interfaz de la clase al eliminar el parámetro del constructor de dependencias, creo que la cura es peor que la enfermedad por un par de razones. Primero, y esto es muy importante para mí, esto hace que su programa dependa de un archivo de configuración externo. Si necesita una implementación binaria única, simplemente no puede usar este tipo de contenedores. El segundo problema es que la API ahora es débil y peor, tipada en cadena . La evidencia (en este ejemplo hipotético) es el argumento de cadena del contenedor de IoC y el reparto del resultado.
Entonces, ¿hay otros beneficios de usar este tipo de contenedores o simplemente no estoy de acuerdo con los que recomiendan los contenedores?