Applications consist of multiple classes which collaborate with each other. For example an instance of class A needs an instance of class B and C to do its job; in other words, class A depends on class B and C; class B and C are thus dependencies of class A.
There are three options to satisfy dependencies:
- hard-code dependencies,
- look up dependencies,
- use the Dependency Injection pattern.
1. Hard-coding dependencies is the easiest strategy: class A simply instantiates its dependencies.
-
class A {
-
-
private var b:B;
-
private var c:C;
-
-
public function A() {
-
b = new B(3, true);
-
c = new C();
-
}
-
-
public function doSomething() {
-
var r:String = b.doSomething();
-
c.doSomething(r);
-
}
-
-
}
Problems of hard-coding dependencies:
- Configuration is distributed across the whole application (configuration is in this case wiring up the instances and configuring dependent instances).
- Class A must be modified to exchange a dependency (tight coupling): the instance of B may be replaced by an instance of SubB which fulfils the same contract as its super-class B. If B were an interface than any implementations could be used to satisfy the dependency.
- What if a fourth class D has a dependency to the same instance of B as class A?
2. Looking up dependencies requires a context: class A gets the context and looks up its dependencies.
-
class A {
-
-
private var b:B;
-
private var c:C;
-
-
public function A() {
-
var context:Context = Context.getInstance();
-
b = context.getB();
-
c = context.getC();
-
}
-
-
…
-
-
}
Advantages of looking up dependencies:
- Partially centralized configuration of the context: dependency b is already fully configured; but every instance looks up its dependencies on its own.
- One instance can be used to satisfy multiple dependencies: an instance of class D can simply use context.getB() to get the same instance.
Problems of looking up dependencies:
- Class A depends on a context: makes unit testing more difficult and the look ups are disturbing.
- Code is bloated with dependency look-ups.
3. Using the Dependency Injection pattern is simple and places no requirements: class A provides ways to inject dependencies.
Advantages of dependency injection:
- Configuration is centralized in one place: both configuration of instances and wiring up instances.
- Dependencies can be exchanged easily (loose coupling).
- Wiring up instances is made easy.
Problem of dependency injection: The wiring code may become rather complex if there are a lot of instances with a lot of dependencies to satisfy.
One way to go is to use Constructor Injection. In this approach class A declares a constructor with paramters for both dependencies; the dependencies are given on instantiation.
-
class A {
-
-
private var b:B;
-
private var c:C;
-
-
public function A(b:B, c:C) {
-
this.b = b;
-
this.c = c;
-
}
-
-
…
-
-
}
Advantages of constructor injection:
- Dependencies cannot be changed after instantiation.
- Initialization which requires all dependencies can be done directly in the constructor.
- Instance is not in illegal state after instantiation.
Problems of constructor injection:
- Parameter list of constructor may become very long (there may be a lot of dependencies, plus other information to pass to the constructor).
- Parameters are distinguished by index and not by name, which may make the code harder to understand.
Another way to go is Setter Injection. In this approach class A provides setters for both dependencies; the dependencies are satisfied after instantiation.
-
class A {
-
-
private var b:B;
-
private var c:C;
-
-
public function A() {
-
}
-
-
public function setB(b:B):Void {
-
this.b = b;
-
}
-
-
public function setC(c:C):Void {
-
this.c = c;
-
}
-
-
…
-
-
}
Advantages of setter injection:
- Constructor can be used to pass other information than dependencies.
- Code is easier to understand because names rather than indices are used to distinguish dependencies.
Problems of setter injection:
- Dependencies may not have been satisfied when needed.
- Dependencies may be changed after ‘official’ initialization.
- Initialization may have to be done after all dependencies are satisfied: init-method is needed.
While dependency injection is a pattern with many advantages, there are also some problems when used extensively, which can only be solved by an Inversion of Control Container. Such a container provides means of managing instances: lifecycle management (instantiating classes, setting dependencies, invoking init-methods, destroying classes), looking up managed instances, configuring managed instances, resolving dependencies.
In my following articles I’m going to present the As2lib Inversion of Control Container and show you how it solves the problems mentioned above and which other functionalities it provides (for example using its generic XML dialect to create UIs with ActionStep, AsWing, EnFlash or any other component library).
Further Reading: Inversion of Control Containers and the Dependency Injection pattern
3 Responses to “Dependency Injection”
Thnaks for the run down.
Nice article! Thanks for explanation! Somehow I end up with the constructor injection naturally most of the time but Setter injections might be much more clean.
Hi Sascha and Chris,
thanks for the responses!
I also used to use constructor injection most of the time, because every instance is in a legal state directly after instantiation. But with the help of an inversion of control container and supported init-methods that make sure that the instance is an a legal state, setter injection is the more convenient way to go.
If I use settern injection without an IoC container I normally use default instances that are used if no custom one was set.
Cheers,
Simon