Injizieren Abhängigkeiten in Methoden oder im Konstruktor?

Question

Dependency Injection scheint eine gute Sache zu sein. Im Allgemeinen sollten Abhängigkeiten bei den Methoden injiziert werden, die sie benötigen, oder sollten sie in der contructor der Klasse injiziert werden?

Sehen Sie die Proben unter den beiden Möglichkeiten zu zeigen, die gleiche Abhängigkeit zu injizieren.

//Inject the dependency into the methods that require ImportantClass
Class Something {

    public Something()
    {
         //empty
    }

    public void A() 
    {
         //do something without x
    }

    public void B(ImportantClass x)
    {
         //do something with x
    }

    public void C(ImportantClass x)
    {
         //do something with x
    }
}

//Inject the dependency into the constructor once
Class Something {
    private ImportantClass _x
    public Something(ImportantClass x)
    {
         this._x = x;
    }

    public void A() 
    {
         //do something without x
    }

    public void B()
    {
         //do something with this._x
    }

    public void C()
    {
         //do something with this._x
    }

}

Answer 1

Der große Vorteil der Konstruktor Injektion ist, dass es Ihre Felder erlaubt endgültig zu kennzeichnen. Zum Beispiel:

class Foo {
    private final Bar _bar;

    Foo(Bar bar) {
        _bar=bar;
    }
}

Die folgende Seite hat eine große Liste der Vor-und Nachteile des Guice Best Practices :

Methode Injektion

• + Ist das nicht Feldeinkopplung
• + Das einzige, was für einige seltsame Grenzfälle
funktioniert

Constructor Injektion

• + Felder kann der Vorrat reicht!
• + Injektion kann nicht möglicherweise übersprungen wurden
• + Leicht zu sehen Abhängigkeiten auf einen Blick
• + Es ist, was die Idee der Konstruktion dreht sich alles um
• - Keine optional Injektionen
• - Nutzlos, wenn DI-Bibliothek kann nicht Instanziierung selbst
• - Subklassen müssen „wissen“ die benötigten Injektionen von ihren Oberklassen
• - weniger bequem für die Tests, die nur „kümmern sich um“ einen der Parameter

Answer 2

Durch die nicht die Abhängigkeit bei jeder Methode Injizieren Sie dann jeden Anrufer zwingen, zu wissen, oder die Abhängigkeit abgerufen werden.

Auch von einer Werkzeug Sicht gibt es viele Frameworks (zumindest in .NET), die zu tun, aktiviert oder Konstruktor Injektion viel einfacher. Dies sollte nicht die Entscheidung beeinflussen, sondern macht es viel attraktiver.

Viel Glück.

Answer 3

Wenn Sie während der Methoden injizieren, als Sie die Verhalten Abstraktion von den konkreten Abhängigkeiten nicht zu unterscheiden. Dies ist ein großer nein nein :). Sie wollen sich auf Abstraktionen abhängen, so dass Sie nicht mit den Abhängigkeiten der Klassen Abhängigkeiten gekoppelt sind. . .

Da Ihr Konstruktor nicht, dass es in jeder Schnittstelle sein würde, die Ihre konkrete Klasse unterstützt, als Sie nicht auf diese Abhängigkeit Kopplung sind. Aber die Methodenaufrufe würde dieses Problem haben.

Hier ist ein guter Artikel auf dieser tiopic:

http: // chrisdonnan.com/blog/2007/05/20/conquest-through-extreme-composition-glue-part-2/

Answer 4

Eine andere Methode ist, um Benutzer eine Setter für die Abhängigkeit. Manchmal wird dies mit Konstruktor Injektion kombiniert. Dies kann nützlich sein, wenn Sie ändern möchten, welche Implementierung Sie verwenden später, ohne die Instanz neu erstellen zu müssen.

public interface IFoo
{
   void Do();
}

public class DefaultFoo : IFoo
{
   public void Do()
   {
   }
}

public class UsesFoo
{
   private IFoo foo;
   public IFoo Foo
   {
       set { this.foo = value; }
   }

   public UsesFoo()
   {
      this.Foo = new DefaultFoo();
   }

   public UsesFoo( IFoo foo )
   {
      this.Foo = foo;
   }

   public void DoFoo()
   {
      this.Foo.Do();
   }
}

Answer 5

verrückt Bob Lee sagt Verwendung Konstruktor Injektion wann immer möglich. Nur Methode Injektion verwenden, wenn Sie (wie in einem Servlet) keine Kontrolle über Instanziierung haben.