Bonnes pratiques IoC & Interfaces

Question

J'expérimente IoC sur mon chemin vers TDD en jouant avec un projet existant. En résumé, ma question est la suivante: quelles sont les meilleures pratiques en matière d'IoC lorsque les méthodes publiques et non publiques présentent un intérêt?

Il existe deux classes:

public abstract class ThisThingBase 
{ 
    public virtual void Method1() {} 
    public virtual void Method2() {} 

    public ThatThing GetThat() 
    { 
     return new ThatThing(this); 
    } 
    internal virtual void Method3() {} 
    internal virtual void Method4() {} 
} 

public class Thathing 
{ 
    public ThatThing(ThisThingBase thing) 
    { 
     m_thing = thing; 
    } 
    ... 
} 

ThatThing fait quelques trucs en utilisant la référence ThisThingBase pour appeler des méthodes qui sont souvent surchargées par les descendants de ThisThingBase.

La méthode 1 et la méthode 2 sont publiques. Method3 et Method4 sont internes et seulement utilisés par ThatThings.

Je voudrais tester ThatThing sans ThisThing et vice-versa.

En étudiant IoC, j'ai d'abord pensé que je devais définir une interface IThing, l'implémenter par ThisThingBase et la transmettre au constructeur ThatThing. IThing serait l'interface publique que les clients pourraient appeler mais elle n'inclut pas Method3 ou Method4 dont ThatThing a également besoin.

Devrais-je définir une deuxième interface - IThingInternal peut-être - pour ces deux méthodes et passer les deux interfaces à ThatThing?

Answer 1

Le problème avec les conteneurs IoC est lorsqu'ils ne peuvent pas contrôler le cycle de vie des objets. Pourquoi la méthode d'usine sur ThisThingBase? S'il était possible de construire le conteneur IoC, cela augmenterait la testabilité.

Il est difficile de dire sur la base de l'exemple, mais il est possible que vous ayez un couplage inutile entre Thatthing et ThisThingBase.

Les interfaces peuvent être bonnes, mais parfois, cela suffit avec les méthodes virtuelles sur la classe dont vous dépendez pour activer le test.