How DI can be implemented depends very much on the language used.
Here is a simple non-DI example:
class Foo {
private Bar bar;
private Qux qux;
public Foo() {
bar = new Bar();
qux = new Qux();
}
}
This sucks, e.g. when for a test I want to use a mock object for bar. So we can make this more flexible and allow instances to be passed via the constructor:
class Foo {
private Bar bar;
private Qux qux;
public Foo(Bar bar, Qux qux) {
this.bar = bar;
this.qux = qux;
}
}
// in production:
new Foo(new Bar(), new Qux());
// in test:
new Foo(new BarMock(), new Qux());
This already is the most simple form of dependency injection. But this still sucks because everything has to be done manually (also, because the caller can hold a reference to our internal objects and thus invalidate our state).
We can introduce more abstraction by using factories:
One option is for the Foo to be generated by an abstract factory
interface FooFactory {
public Foo makeFoo();
}
class ProductionFooFactory implements FooFactory {
public Foo makeFoo() { return new Foo(new Bar(), new Baz()) }
}
class TestFooFactory implements FooFactory {
public Foo makeFoo() { return new Foo(new BarMock(), new Baz()) }
}
FooFactory fac = ...; // depends on test or production
Foo foo = fac.makeFoo();
Another option is to pass a factory to the constructor:
interface DependencyManager {
public Bar makeBar();
public Qux makeQux();
}
class ProductionDM implements DependencyManager {
public Bar makeBar() { return new Bar() }
public Qux makeQux() { return new Qux() }
}
class TestDM implements DependencyManager {
public Bar makeBar() { return new BarMock() }
public Qux makeQux() { return new Qux() }
}
class Foo {
private Bar bar;
private Qux qux;
public Foo(DependencyManager dm) {
bar = dm.makeBar();
qux = dm.makeQux();
}
}
The remaining problems with this are that we need to write a new DependencyManager subclass for each configuration, and that the number of dependencies which can be managed is fairly restricted (each new dependency needs a new method in the interface).
With features like reflection and dynamic class loading we can circumvent this. But this depends very much on the language used. In Perl, classes can be referenced by their name, and I could just do
package Foo {
use signatures;
sub new($class, $dm) {
return bless {
bar => $dm->{bar}->new,
qux => $dm->{qux}->new,
} => $class;
}
}
my $prod = { bar => 'My::Bar', qux => 'My::Qux' };
my $test = { bar => 'BarMock', qux => 'QuxMock' };
$test->{bar} = 'OtherBarMock'; # change conf at runtime
my $foo = Foo->new(rand > 0.5 ? $prod : $test);
In languages like Java, I could have the dependency manager behave similar to a Map<Class, Object>:
Bar bar = dm.make(Bar.class);
To which actual class the Bar.class is resolved can be configured at runtime, e.g. by maintaining an Map<Class, Class> which maps interfaces to implementations.
Map<Class, Class> dependencies = ...;
public <T> T make(Class<T> c) throws ... {
// plus a lot more error checking...
return dependencies.get(c).newInstance();
}
There is still a manual element involved in writing the constructor. But we can make the constructor completely unnecessary, e.g. by driving the DI via annotations:
class Foo {
@Inject(Bar.class)
private Bar bar;
@Inject(Qux.class)
private Qux qux;
...
}
dm.make(Foo.class); // takes care of initializing "bar" and "qux"
Here is an example implementation of a tiny (and very restricted) DI framework: http://ideone.com/b2ubuF, although this implementation is completely unusable for immutable objects (this naive implementation cannot take any parameters for the constructor).
