Traitement des relations et des incohérences potentielles avec DI/IoC

Question

J'ai des difficultés à concevoir des classes pour utiliser au mieux les principes DI/IoC, en particulier lorsqu'une classe partage une dépendance avec l'une de ses dépendances (par exemple, X a des dépendances Y et Z, et Y a la dépendance Z).

Un exemple sera probablement utile:

Disons que j'ai une classe qui encapsule des informations de connexion pour mon application. Appelez ce ConnectionInfo '

class ConnectionInfo 
{ 
    // ... 
} 

J'ai créé une classe ouvrière qui utilise les informations de connexion, donc je vais injecterait mes dépendances par le constructeur.

class Worker 
{ 
    public Worker(ConnectionInfo c) 
    { 
     // ... 
    } 
} 

Maintenant, disons que je veux construire une autre classe. Il a besoin d'accéder aux informations de connexion, mais je souhaite également avoir accès aux fonctionnalités fournies par la classe Worker.

class AnotherClass 
{ 
    public AnotherClass(ConnectionInfo c, Worker w) 
    { 
     // ... 
    } 
} 

Tout cela est très bien. Cependant, il existe une relation logique implicite entre l'objet ConnectionInfo injecté dans le Worker et l'objet ConnectionInfo injecté dans la classe AnotherClass. La conception n'a de sens que lorsqu'ils sont identiques. Ce n'est pas appliqué, cependant. Rien n'interrompt l'injection d'un ConnectionInfo dans AnotherClass, et un ConnectionInfo complètement indépendant est injecté dans Worker. Est-ce que je fais face à IoC/DI dans le mauvais sens?
Les classes doivent-elles être conçues différemment ou les problèmes devraient-ils être traités d'une autre manière (par exemple, en appliquant la validation des paramètres, ou peut-être simplement en les laissant au conteneur IoC)?

Answer 1

Je ne pense pas qu'il y ait un problème avec la conception de classe

lorsque votre code client a besoin d'un objet de AnotherClass que cela va créer ses propres dépendances de ConnectonInfo et des travailleurs.

Il existe actuellement 2 scénarios.

1- Votre ConnectionInfo et votre Worker sont des Singletons: dans ce cas, si vous créez un objet AnotherClass, les mêmes objets de ConnectionInfo et Worker seront partagés par AnotherClass.

2- Si le point 1 n'est pas vrai: À chaque fois que vous créez votre classe Anotehr, Container injectera des dépendances en tant que nouveaux objets. Mais pour ConnectionInfo, je pourrais dire qu'il peut s'agir d'un objet Sigleton parce que c'est l'information commune dont votre application a besoin, donc je dirais que faire ConectionInfo comme Singleton et que ça reste bien, je ne pense pas que vous violez toutes les règles de l'IoC.