What is Dependency injection (DI) ?, What is Dagger? And how do they help us write code in a cleaner and easier way to test? In this article we will learn about them.
I. Introduction
1. Concepts
a. Dependency injection
Before learning about Dagger – which uses DI, let’s learn about DI first
We have the following example:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 | public class WeatherReporter { private final WeatherService weatherService; private final LocationProvider locationProvider; public WeatherReporter() { weatherService = new WeatherService(); locationProvider = new LocationProvider(); } public void report() { Location location = locationProvider.getCurrentLocation() Temperature temperature = weatherService.getTemperature(location) print(temperature) } } |
In OOP programming a good design is a class that only has a clear responsibility and depends on other objects to get the job done. These objects are called dependencies .
Before the class can run, the objects it depends on must be provided in some way.
In the above example, we instantiate 2 objects right in the WeatherReporter class
- WeatherService : provides weather information
- Location : provide location
You see normal, no problem right? But there are 2 issues as follows:
- First , when we do not use WeatherService anymore, such as using some GoogleWeatherService , why ?? Well … we have to change the WeatherReporter class into that Google and go to each other class to use WeatherService to change
- Second : We still use the other WeatherService class – great too unchanged. However, for example, the time the function initializes takes parameters, like new WeatherService (season) – get the weather by season. ==> We have to change here and … many other places.
==> How to initialize on many shortcomings, not reasonable.
We will move on to the next example
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 | public class WeatherReporter { private final WeatherService weatherService; private final LocationProvider locationProvider; public WeatherReporter(WeatherService weatherService, LocationProvider locationProvider) { this.weatherService = weatherService; this.locationProvider = locationProvider; } public void report() { Location location = locationProvider.getCurrentLocation() Temperature temperature = weatherService.getTemperature(location) print(temperature) } } |
What do we see? Other than the above, we pass the WeatherService and LocationProvider objects in and out via the constructor. Rather than initializing the object directly inside.
Has the above two issues been resolved yet ?? The answer is completely solved already:
- GoogleWeatherService : we will not need to go to each class used to fix it but will do as below.
- Parameters : already initialized outside, how many parameters are the same.
I do the following
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 | public interface WeatherService { Temperature getTemperature(); } public interface LocationProvider { Location getCurrentLocation(); } public class Main { public static void main(String args[]) { WeatherService ws = new GoogleWeatherService(); LocationProvider lm = new GoogleLocationProvider(); WeatherReporter reporter = new WeatherReporter(ws, lm); reporter.report(); } } |
As above method:
- WeatherService , LocationProvider converted to interface. The WeatherReporter class receives external dependencies.
- Dependencies can be any implementation of interface 2 above, when there is a change in the WeatherService example from Google to Yahoo, just change a single line of external code instead of having to edit each class to use the dependency location.
Done, so the issues have been resolved. Just use it.
overview
Dependency Injection is built on the concept of Inversion of Control .
This means that the dependencies of a class should only be provided externally. Simply understand, no class can initialize the object of another class (dependent class) inside it, but should get that dependent class from a configuration class.
The greatest effect of using Depedency Injection is that it can increase the reuse of classes, making the classes completely independent of each other.
But try to look a little further !!! If the project only has that many objects, very few dependencies, then there is no problem with the DI.
Consider the following example:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 | public class Main { public static void main(String args[]) { WebSocket webSocket = getWebSocket()); WeatherService weatherService = new GoogleWeatherService(webSocket); GPSProvider gps = new GoogleGPSProvider(); ExploreService explore = new GoogleExploreService(); LocationProvider location = new GoogleLocationProvider(gps, explore); WeatherReporter reporter = new WeatherReporter(weatherService, location); reporter.report(); } private static WebSocket getWebSocket() { SocketConfig conf = FileConfigReader.read("./tmp/web.yaml") return new WebSocketImpl(conf.getHost(), conf.getPort()) } } |
LocationProvider has its dependencies GPSProvider for current location, ExploreService to provide interesting places around, WeatherService needs WebSocket to communicate with the hydro-meteorological station.
Imagine that WebSocket, GPSProvider , … have its own dependencies, and the way to initialize is not simply a new line but must read the file, logically initialize, … this time the main function will be a mess.
However, if you use Dagger, the example above will become simple like this
1 2 3 4 5 6 7 8 | public class Main { public static void main(String args[]) { AppComponent component = DaggerAppComponent.create(); WeatherReporter reporter = component.getWeatherReporter(); reporter.report(); } } |
Read the next section to find out why – how to use it
2. Reason for use
Dagger 2 is an open source that helps us automatically generate codes, create a dependency graph based on the Annotation when compile time. While some other frameworks, such as Spring, DI is implemented based on reflection, making it slower at runtime.
Because the code will genuinely give us dependencies, the code will be shorter, much simpler.
Dependencies are automatically generated without the need to write code yourself and put it into contructors
Before dagger 2 there was dagger 1 , you can still use it, but not recommended: v The reason is as follows
In the past, there was a framework that analyzed the dependency of a class (see which classes that class depends on). After analysis, this framework initializes the dependent classes and embeds them into the original class via Java Reflection . As such these classes can be independently tested. The framework we are talking about is Dagger 1.
But the operation of Dagger 1 has 2 disadvantages:
- First: Reflection is very slow
- Second: Dagger 1 creates objects that the base class depends on at the time of Runtime , which can lead to unexpected errors.
So let’s move on to Dagger 2 But dagger 1 has also been deprecated already (September 15, 2016).