In this article we will explore some of the benefits of dependency injection and how this can be used in all types of programming, including small and simple programs. Some of the example shown below make use of Guice, a dependency injection framework by Google. The same concept applies for any other dependency injection framework.
This article does not provide detailed description of Guice but it only focus on the benefits of dependency injection and design methods that improve modularity, extendibility and testing.
What is dependency injection?
Let say we want to make some tea. How would we do it and what do we need? We need to boil some water, a clean mug, tea bags, sugar and milk (at least that's what I put into mine). In order to make tea we need to provide all these ingredients and we need to manage all these ourselves. We have to fill the kettle with water and heat it up, get the milk from the refrigerator and get the rest.
Now assume that we can make tea, by simply asking someone else to do it for us. Someone that knows how to do the tea just the way we want it. Would that be better than making the tea ourselves? If yes, then welcome to dependency injection.
Dependency injection is a framework that takes care of creating objects for us without we having to worry about providing the right ingredients so to say.
A Simple Example
Let say we have a class, Person, and this class needs to send a message. The Person class requires the aid of some other class, Email, in order to send a message.
Following is a simple way of doing this.
public class Email {
public void sendEmail(String subject, String message){
}
}
public class Person {
private Email email = new Email();
public void greetFriend(){
email.sendEmail(parameters...);
}
}
Some code is omitted from the above classes for brevity
We all agree that this is a very simple and straight forward example that involves two simple Java classes. Nevertheless, the above has some limitations as listed below.
- The
Personsclass is dependent (has a strong/tight dependency) on theEmailclass. There is a hard connection between these two classes. Let say we have a new better version of email class,FastEmail, in order for us to use it, we need to go in each and every class that depends on theEmailclass, such as thePersonclass, replace it with the new version. - Let say we parametrise the
Email's constructor. Again we have to go in each and every class that is initialising theEmailclass, such as thePersonclass, and change it. - A design decision is taken to make the
Emailclass singleton. Similar to above we need to modify all instances where it is used. - In order to improve the notifications/messages system, we decide to add different message delivery systems such as SMS or tweets. The
Personclass and other like it, need to all be modified in order for it to use the new classes. - Another developer needs to use the
Personclass, but would like to use a different notification/message system. This cannot be achieved with the current version of thePersonclass as it is hardwired to theEmailclass. What generally happens is that the other developer duplicates thePersonclass and modifies it as he/she needs. The projects ends up with two versions of thePersonclass. - In the above points we mentioned many scenarios where code has to be changed. All changes made, need to and should be tested. How can we test the
Personclass without including the message delivery class such as theEmail? Testing, in many cases, is left as an afterthought. The way we have thePersonclass constructed makes it hard to test it without involving theEmailclass. Furthermore, how would we automate such test? How can we use JUnit or the like to automate out tests? - Moving forward in the project, the
Personclass starts to depend on another class that allow this object to write a letter using thePenclass for example. ThePersonclass can use other ways to write a letter, such asPencilclass orTypewriterclass, but this approach does not allow that.
These limitations can be improved by changing the way we think and restructure our code in a modular way. This is independent from dependency injection as we will see in the following section.
Change the way we think
The Email class provides a service, that is, sending of messages over the Internet using the mail protocol. Instead of having the Person class initialising an instance of the Email class, we first create an interface, MessageService, and make the Person class using this interface instead. This removed the dependency that the Person class has on the Email and replaces it with an abstract message delivery interface.
The following three steps: define, implement and use, show how we can develop modular and extendable code. This approach also improves testing as we will see at the end of this article.
- Define Interfaces
Many developers do not use interfaces as they see them as additional non-required code. This may be true (I said maybe as the
Systemclass makes use of interfaces) for the famous hello world program, definitely not true for the rest. Like with everything else, we have to see things in context and there will be cases when we can do without interfaces. Nevertheless, developing code using interfaces produce far more modular and extendable code as illustrated in the following examples. The example discussed in the previous section was quite simple, but nevertheless it included several pitfalls which can be easily avoided. Changing code at a later stage involves more work than having it right in the first place.We start by defining the
MessageServiceinterface that includes one method,sendMessage(String subject, String message). For simplicity we assume that no exceptions are thrown.public interface MessageService { void sendMessage(String subject, String message); } - Implement Interfaces
In the list of limitations we mentioned four possible methods of sending a message: email, fast email, SMS and tweet. Let's create four classes that handle each message delivery method and have all these classes implement the interface created above.
public class EmailService implements MessageService { @Override public void sendMessage(String subject, String message){ System.out.printf("Email: %s, %s%n ", subject, message); } } public class FastEmailService implements MessageService { @Override public void sendMessage(String subject, String message){ System.out.printf("Fast Email: %s, %s%n ", subject, message); } } public class SMSService implements MessageService { @Override public void sendMessage(String subject, String message){ System.out.printf("SMS: %s, %s%n ", subject, message); } } public class TweetService implements MessageService { @Override public void sendMessage(String subject, String message){ System.out.printf("Tweet: %s, %s%n", subject, message); } } - Use Interfaces
Finally, instead of using classes, we use interfaces. In the
Personclass, we replace theEmailfield with theMessageServiceservice interface as shown in red below.public class Person { private MessageService messageService; public Person(MessageService messageService){ this.messageService = messageService; } public void greetFriend(){ messageService.sendMessage(parameters...); } }Note that the
Personclass is not initialising the message service but it is expecting it as a parameter of its constructor. This is a key element in the design. It improves modularity, extendibility and testing. ThePersonclass is not dependent on any implementation, but on a service defined by an interface. This means that we can use thePersonclass without having to worry about the underlying implementation. Furthermore, differentPersoninstance can be instantiated using different message services.
One can argue that the new version of Person class became more complex to instantiate as it requires parameters. This is a fair statement and here is when dependency injection comes into play.
Using Dependency Injection
As mentioned in the introduction, dependency injection can help us initialising objects and provide these objects all the necessary resources (ingredients). For example, the Person class requires an instance of MessageService. The dependency injection framework will provide that for us. So to create an instance of Person, all we need to do is call something like: dependecyFramework.getInstance(Person.class). Magically, (not really), the dependency injection framework will create an instance of the Person class and provide an instance of the a MessageService to the Person object.
The next natural question will be, how does the dependency injection framework knows how to initialise the MessageService? We need to tell the dependency injection framework how to create an instance of MessageService. With Google Guice we do that by creating a module (extends AbstractModule ) as illustrated below:
public class ProjectModule extends AbstractModule {
@Override
protected void configure() {
bind(MessageService.class).to(EmailService.class);
}
}
Here we are telling the dependency injection how to create an instance of the MessageService class. We also need to add an annotation to the Person class in order to allow the dependency injection framework to inject the necessary parameters.
public class Person {
private MessageService messageService;
@Inject
public Person(MessageService messageService){
this.messageService = messageService;
}
public void greetFriend(){
messageService.sendMessage(parameters...);
}
}
With everything set, we create an instance of the Person class using the dependency injection framework
Injector injector = Guice.createInjector(new ProjectModule()); Person person = injector.getInstance(Person.class); person.greetFriend();
We replaced a couple of lines of code with many others. What's the buzz about this? In the next section we will see some of the benefits of dependency injection and how this can be used to simplify our coding life
Benefits of Dependency Injection
In this section we will see some key benefits of dependency injection
- Changing the message service
Let's change the delivery method from email to SMS. How would we do that?
We only need to change the
ProjectModuleclass to map theMessageServiceclass to theSmsServiceclass as shown in red below.public class ProjectModule extends AbstractModule { @Override protected void configure() { bind(MessageService.class).to(SmsService.class); } }This one change will affect all classes initialised with the dependency injection framework without having to change any of these classes. This leads us to another advantage, testing.
- Changing the message service
We can create a
MockServiceclass which can be using in JUnit test as shown next.public class MockService implements MessageService { public String subject; public String message; @Override public void sendMessage(String subject, String message) { this.subject = subject; this.message = message; } }The above mock message service simply stores the parameters into two public fields. These fields can be used to retrieve the values of the parameters and used for testing ass illustrated next.
public class TestPerson { private Injector injector; @Before public void init() { injector = Guice.createInjector(new AbstractModule() { @Override protected void configure() { bind(MockMessageService.class).in(Singleton.class); bind(MessageService.class).to(MockService.class); } }); } @Test public void testGreetFriend() { Person person = injector.getInstance(Person.class); person.greetFriend(); MockService mockService = injector .getInstance(MockService.class); assertEquals("Greet", mockService.subject); assertEquals("Hello my friend", mockService.message); } }This may require some explanation. So here we go. We created an injection (Guice dependency injection) just for this testing and provided a custom module (as an abstract inner anonymous class). The custom module wires the
MessageServicewith theMockServiceinstead. Also, we set theMockServiceas singleton, that is, whenever we request an instance of this class from the injection we always get the same object (singleton). AftergreetFriend()is invoked, we test using JUnit to make sure that the correct parameters are being passed to the message service instance.This design setup allows us to test the
Personclass independent from the other classes that it depends on in an automated manner. - Changing the signature of the
PersonconstructorAs we mentioned in the limitations, the
Personclass may evolve and include more functionality. Changing the signature of thePersonconstructor will not affect us as long as the injector knows how to provide the required parameters.public class Person { @Inject public Person(MessageService messageService, WritingService writingService){ } }The
Personclass will still be initialised in the same way as it is now. Thus changing thePersonconstructor signature will not affect the other classes that make us of it.Person person = injector.getInstance(Person.class);The same applies for anything that is initialised and handled through the injector.
- Passing the
Injectoras parameterIn a project we can have one instance shared throughout the project. This can be achieved by passing the Injector as a parameter to other objects that needs it. We setup the injector at the beginning (in a main method for example), and then have it set as a constructor parameter in all the classes that require an instance of the injector. Like that one injector will server all classes in the project.
Conclusion
This ended up to be quite a long article. Dependency injection is quite simple to use and it has quite a "shallow" learning curve. This article does not explain how to use the actual dependency injection framework (such as Guice). Articles about that are easily found. This article described key benefits of using a dependency injection framework even in small projects.
