Я бачив декілька, які рекомендують використовувати контейнери IoC в коді. Мотивація проста. Візьміть наступний код введеної залежності:
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
}
В:
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>
(Наведене вище є гіпотетичним прикладом C ++)
Хоча я погоджуюся, що це спрощує інтерфейс класу, видаляючи параметр конструктора залежності, я вважаю, що вилікування гірше, ніж захворювання, з кількох причин. По-перше, і це для мене велике, це робить вашу програму залежною від зовнішнього файлу конфігурації. Якщо вам потрібен єдиний бінарний розгортання, ви просто не можете використовувати такі типи контейнерів. Друге питання полягає в тому, що API зараз слабко і гірше, строго набраний. Доказом (у цьому гіпотетичному прикладі) є аргумент рядка до контейнера IoC та подання на результат.
Отже .. Чи є інші переваги використання таких видів контейнерів чи я просто не згоден з тими, які рекомендують контейнери?