¿Inyectar dependencias en métodos o en el constructor?

Question

La inyección de dependencia parece ser algo bueno. En general, ¿deberían inyectarse dependencias en los métodos que las requieren, o deberían inyectarse en el contralor de la clase?

Vea los ejemplos a continuación para demostrar las dos formas de inyectar la misma dependencia.

//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

El principal beneficio de la inyección de constructores es que permite que sus campos se marquen como finales. Por ejemplo:

class Foo {
    private final Bar _bar;

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

La siguiente página tiene una gran lista de los pros y los contras: Guice Best Practices :

Inyección de método

• + No es inyección de campo
• + Lo único que funciona para algunos casos extraños de borde

Inyección del constructor

• + ¡Los campos pueden ser finales!
• + La inyección no puede haberse omitido
• + Dependencias fáciles de ver de un vistazo
• + Es de lo que trata la idea de construcción
• - No hay inyecciones opcionales
• : inútil cuando la biblioteca DI no puede hacer una instanciación en sí misma
• - Las subclases deben " conocer acerca de " las inyecciones necesarias por sus superclases
• - Menos conveniente para las pruebas que solo " se preocupan por " uno de los parámetros

Answer 2

Al no inyectar la dependencia en cada método, obliga a cada persona que llama a conocer o recuperar la dependencia.

También desde el punto de vista de las herramientas, hay muchos marcos disponibles (al menos en .NET) que permiten o hacen que la inyección del constructor sea mucho más fácil. Esto no debería influir en la decisión, sino que la hace mucho más atractiva.

Buena suerte.

Answer 3

Si se inyecta durante los métodos, no está diferenciando la abstracción de comportamiento de las dependencias concretas. Este es un gran no no :). Desea depender de las abstracciones para que no esté acoplado con las dependencias de las dependencias de sus clases. . .

Dado que su constructor no estaría allí en ninguna interfaz que su clase concreta admita, usted no se está acoplando a esa dependencia. Pero las llamadas al método tendrían ese problema.

Aquí hay un buen artículo sobre este tema:

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

Answer 4

Otro método es utilizar un configurador para la dependencia. A veces esto se combina con inyección de constructor. Esto puede ser útil si desea cambiar la implementación que está utilizando más adelante sin tener que volver a crear la instancia.

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

Crazy Bob Lee dice que debes usar la inyección del constructor siempre que sea posible. Solo use la inyección de métodos cuando no tenga control sobre la creación de instancias (como en un servlet).