Design Patterns: Dependency Injection

Dependency injection is one of the most useful patterns I have learned since becoming a professional developer.  In my opinion it makes code easier to read and enforces me to make reusable code with the ability to unit test at very granular level.

“Dependency injection” sounds really complicated, but the idea behind dependency injection is simple.

For any objects a particular class is dependent on, rather than creating them explicitly in that class, the dependencies should be injected by becoming parameters of the constructor or properties which are assignable after the object is created.

This is a somewhat simple example, let’s say we have a class named FordTaurus.  In every FordTaurus there is an engine(unless it’s in a junk yard). Let’s say I have a specific model of car and decide that it should have a V6 block in it. So when in the Ctor, I naturally assign the V6Engine to the EngineBlock property.

public class FordTaurus {
	public Engine EngineBlock { get; private set; }

	public FordTaurus() {
		EngineBlock = new V6Engine();

public class Engine { /* ... */ }		
public class V6Engine : Engine { /* ... */ }

While this does work, I’ve made my Taurus dependent on the Engine. Let’s say the V6Engine required a parameter, how would I pass that in to the V6Engine? I would have to pass it in to the FordTaurus class itself somehow.

Well using a dependency injection paradigm, I would change my code to be something like this.

public class FordTaurus {
	public Engine EngineBlock { get; private set; }

	public FordTaurus(Engine e) {
		EngineBlock = e;

Now that the dependency has been moved to be passed into the constructor, I no longer need to worry about what parameters are required to build the engine. I also have made the class more flexible as I could create a new engine say an Inline4Engine class and pass it into my FordTaurus class to use.

As dependencies are moved to the constructor of code, this can also tend to clutter up the constructor. However, if a class depends on too many other classes, it’s likely violating the single-responsibility principle for SOLID code.

A step further would be to use an interface to abstract the engine. Then I could use techniques such as mocking to unit test the FordTaurus without having to test any functionality in the Engine or it’s sub-classes. I’ll post on that at some future time.

Another common technique used with dependency injection is to inject the dependencies with an IOC (inversion of control) container such as Castle Windsor or Unity. These containers allow the dependencies to be injected at run time based on a set of predefined rules. Using these two patterns in conjunction can be extremely powerful. However, I will examine IOC containers in another post as well.


Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s