The Benefits of Dependency Injection

In this post we firstly describe what dependency injection is, as background, and then articulate what the benefits of dependency injection are. We provide answers to these three questions below and also consider whether dependency injection containers should be used in every project.

  1. What is dependency injection?
  2. What Java frameworks or containers provide dependency injection support?
  3. What are the benefits of dependency injection?

What Is Dependency Injection?

When a particular class has a member variable (also called a field) that is an instance of another class then this is a dependency. How the initialization of instance members  happens and who performs this initialization is the crux of dependency injection or the dependency injection pattern.

Normally, without dependency injection, the particular class would have code to initialize an instance variable in a constructor with the two alternatives to this approach being initializer blocks or final methods.

With dependency injection, an instance of the dependency is provided to our particular class by an external party using either the contructor of the particular class or a setter of the particular class. So the external party is the who, and in term of the how this external party performs either contructor injection or setter injection.

Dependency injection frameworks alleviate the need for factories and the use of new in your Java code. Configuration instructions, via annotations or XML, replace new in your Java code. You may still write factories from time to time, but your code will not depend directly on them.

What Java frameworks provide dependency injection support?

The two major frameworks are the Spring Framework and Google Guice. PicoContainer is another alternative.

What Are The Benefits Of Dependency Injection?

In short your code will be easier to change, easier to unit test and easier to reuse in other contexts. We provides explanations for these benefits below, but before we do so, its worth quoting Anand Rajana [1] in terms of his summary:

It facilitates the design and implementation of loosely coupled, reusable, and testable objects in your software design and implementation by removing dependencies that often inhibit reuse. Dependency injection can help you design your applications so that the architecture [container] links the components rather than the components linking themselves.

Your code will be easier to maintain and easier reuse in other contexts.

This is because your object is handed what it needs to work and since it it freed from the burden of resolving its dependencies. When an object is handed what it need to work in terms of its dependencies by a container such as Spring, this is called inversion of control (IoC). One may wonder, why does this, that is IoC, make maintenance and reuse easier? Its because the components (plain old Java objects) that make up your application are loosely coupled as a result of your objects being handed what they need to work – its far easier to swap out a component as a matter of configuration than it otherwise would have been in a tightly coupled architecture.

It is also because dependency injection promotes programming to interfaces which conceals the implementation details of each dependency and naturally this makes it easier to swap out implementations of a given interface. The combination of your objects being handed what they need to work by an IoC container and programming to interfaces significantly enhances loose coupling.

Finally, it is because the centralized control over the object lifecycle brings with it a host of benefits that enhances the maintainability and re-usability of ones code. For example, Spring’s BeanFactoryPostProcessors are able to modify the definition of any bean in the ApplicationContext‘s BeanFactory before any objects are created. A good example of such a BeanFactoryPostProcessor is a PropertyPlaceholderConfigurer which substitutes ${variables} in an definitions with values from .properties files. In addition, a BeanPostProcessor may wrap your beans in a dynamic proxy and add behaviour to your application logic transparently. A good example of behaviour that can be transparently added is transaction management behavior that has been declaratively specified using annotations.

Your code will have significantly enhanced testability

This is because dependencies can easily be replaced with stubs or mocks in unit tests.

Should Dependency Injection Containers Be Used in Every Project?

This is a matter of opinion and so this will be the authors opinion. In short, the answer is no.

One may wonder why the answer is no. It is because one still needs to motivate why one needs all the benefits that come with using say Spring or Guice in one’s architecture. In short-lived prototyping projects maintainability and unit testing may not be the top priority, it could be that the bulk of the effort is say in producing a GUI prototype or experimenting with new technologies. It could also be that reusability is of no concern. Every project is different and thought and motivation needs to be applied to every technology decision.

To give an example of where the benefits of IoC may not be the top priority. The author was handed a micro project (single developer at a time)  that was in trouble in terms of delivery to the client, the top priority was to show the client results in weekly sprints, and the first decision made was to speed up local development and make the existing code generally comprehensible. This involved introducing Maven, the Maven Jetty plugin, JRebel, significant refactoring and much more. Results where delivered, albeit in a tightly coupled manner with hand rolled singletons (factories) and little unit or integration testing. The project later reached a stage where introducing an IoC container made sense in terms of priorities in order to realise all of the cited benefits, above all to introduce testing automation to stub out cloud services.

Although the short answer is no, its worth noting that the long answer is no but in general yes. More often than not prototyping projects go live, and it is in general unlikely that an application will require no maintenance after it went into production. So one should not set up fellow maintainers or one-self up for failure and 9 times out of 10 (if not 9.9 times out of 10) use IoC containers / dependency injection in order to realise the core benefits and that is code that is easier to change, easier to unit test and easier to reuse in other contexts.

References

  1. Dependency Injection, Slideshare, Anand Rajana
  2. Core Spring. Student Lecture Manual. Version 3.2.
  3. google-guice (its worth listening to the presentation, they provide good examples in their slides)
  4. Inversion of Control Containers and the Dependency Injection Pattern, Martin Fowler, 23 January 2004 (somewhat longwinded)

Leave a Reply

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

WordPress.com Logo

You are commenting using your WordPress.com 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