Inject dependencies in methods or in the constructor? - dependency-injection

Question

Dependency injection seems to be a good thing. In general, should dependencies be injected at the methods that require them, or should they be injected in the contructor of the class?
See the samples below to demonstrate the two ways to inject the same dependency.
//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

The major benefit of constructor injection is that it allows your fields to be marked final. For example:
class Foo {
private final Bar _bar;
Foo(Bar bar) {
_bar=bar;
}
}
The following page has a great list of the pro's and con's: Guice Best Practices:
Method injection
+ Isn't field injection
+ Only thing that works for some strange edge cases
Constructor injection
+ Fields can be final!
+ Injection cannot possibly have been skipped
+ Easy to see dependencies at a glance
+ It's what the idea of construction is all about
- No optional injections
- Useless when DI library can't do instantiation itself
- Subclasses need to "know about" the injections needed by their superclasses
- Less convenient for tests that only "care about" one of the parameters

Answer 2

If you inject during the methods than you are not differentiating the behavioral abstraction from the concrete dependencies. This is a big no no :). You want to depend on abstractions so you are not coupled with the dependencies of your classes dependencies . . .
Since your constructor would not be there in any interface that your concrete class supports than you are not coupling to that dependency. But the method calls would have that issue.
Here is a good article on this tiopic:
http://chrisdonnan.com/blog/2007/05/20/conquest-through-extreme-composition-glue-part-2/

Answer 3

By not injecting the dependency at each method you then force each caller to know or retrieve the dependency.
Also from a tooling standpoint there are many frameworks available (at least in .NET) that enable or make constructor injection much easier to do. This should not sway the decision but makes it much more attractive.
Good luck.

Answer 4

Another method is to user a setter for the dependency. Sometimes this is combined with constructor injection. This can be useful if you want to change which implementation you are using later without having to recreate the instance.
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 says use constructor injection whenever possible. Only use method injection when you don't have control over instantiation (like in a servlet).