Ho visto diversi raccomandare l'uso di contenitori IoC nel codice. La motivazione è semplice Prendi il seguente codice iniettato di dipendenza:
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
}
In:
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>
(Quanto sopra è ovviamente un esempio ipotetico di C ++)
Mentre sono d'accordo sul fatto che ciò semplifichi l'interfaccia della classe rimuovendo il parametro del costruttore di dipendenza, penso che la cura sia peggiore della malattia per un paio di motivi. Innanzitutto, e questo è importante per me, questo rende il tuo programma dipendente da un file di configurazione esterno. Se è necessaria una distribuzione binaria singola, semplicemente non è possibile utilizzare questo tipo di contenitori. Il secondo problema è che l'API è ora debolmente e peggio ancora, tipizzata in modo rigoroso . L'evidenza (in questo ipotetico esempio) è l'argomento stringa al contenitore IoC e il cast sul risultato.
Quindi ... ci sono altri vantaggi nell'uso di questi tipi di contenitori o non sono d'accordo con quelli che raccomandano i contenitori?