Vendez-moi sur des conteneurs IOC, s'il vous plaît

Question

J'ai vu plusieurs recommandations de conteneurs IOC dans le code. La motivation est simple. Prenez le code injecté de dépendance suivant:

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
}

Dans:

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>

(Ce qui précède est un exemple C ++ hypothétique) bien sûr)

Bien que je convienne que cela simplifie l'interface de la classe en supprimant le paramètre du constructeur de dépendances, je pense que le remède est pire que la maladie pour deux raisons. Tout d'abord, et c'est un gros pour moi, cela rend votre programme qui dépend d'un fichier de configuration externe. Si vous avez besoin d'un déploiement binaire unique, vous ne pouvez tout simplement pas utiliser ces types de conteneurs. Le deuxième problème est que l'API est maintenant faiblement et pire, effréné Typé. La preuve (dans cet exemple hypothétique) est l'argument de chaîne du conteneur IOC et le casting sur le résultat.

Alors .. y a-t-il d'autres avantages de l'utilisation de ces types de conteneurs ou est-ce que je ne suis pas d'accord avec ceux qui recommandent les conteneurs?