Solución:
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 pros y contras: Mejores prácticas de Guice:
Inyección de método
- + ¿No es inyección de campo?
- + Lo único que funciona para algunos casos extremos extraños
Inyección de constructor
- + ¡Los campos pueden ser definitivos!
- + No es posible que se haya saltado la inyección
- + Dependencias fáciles de ver de un vistazo
- + De eso se trata la idea de construcción
- – Sin inyecciones opcionales
- – Inútil cuando la biblioteca DI no puede crear una instancia por sí misma
- – Las subclases necesitan “conocer” las inyecciones que necesitan sus superclases.
- – Menos conveniente para las pruebas que solo “se preocupan” por uno de los parámetros
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 de constructores sea mucho más fácil de hacer. Esto no debería influir en la decisión, pero la hace mucho más atractiva.
Buena suerte.
Si inyecta durante los métodos, entonces no está diferenciando la abstracción del comportamiento de las dependencias concretas. Este es un gran no no :). Desea depender de abstracciones para no estar asociado con las dependencias de las dependencias de sus clases. . .
Dado que su constructor no estaría allí en ninguna interfaz que admita su clase concreta, 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 tíope:
http://chrisdonnan.com/blog/2007/05/20/conquest-through-extreme-composition-glue-part-2/