Who should read?
If you’re a budding Android developer, who started with Android directly and learning Java parallely — this is for you. Or if you’re one who tried learning Dagger 2 and you’re finding it little difficult to understand the other online content — don’t worry, I was having a tough time too (we are little special, we need to be explained differently) and this is definitely for you. If you’re already experienced in DI and Dagger, you may pick up something new or get more clarity (or may sound very beginner).
- Dagger 2 for Android Beginners — Introduction (you’re here)
- Dagger 2 for Android Beginners — DI part I
- Dagger 2 for Android Beginners — DI part II
- Dagger 2 for Android Beginners — Dagger 2 part I
- Dagger 2 for Android Beginners — Dagger 2 part II
- Dagger 2 for Android Beginners — Dagger 2 Advanced part I
- Dagger 2 for Android Beginners — Dagger 2 Advanced part II
What is Dependency?
Note : In order to explain the following concept, I’m using the analogy with Game of Thrones. If you’re not familiar with that, please replace the following class names — Targaryens and Dragons with A and B as you proceed. And, you should definitely start watching that series though :-P
Understanding dependency/coupling is the first step in achieving more clarity in object oriented programming concepts. So, what is a dependency? For example, we have a class called
Targaryens which uses another class or interface called
Dragons inside the
Targaryens class — then class
Targaryens depends upon the class or interface
This means that
Targaryens cannot work without
Dragons. This also means that where ever
Dragons needs to be there i.e, we cannot reuse
Targaryens without reusing
Dragons. So in this scenario, the
Targaryens are called the dependants and the
Dragons are called the dependency. A dependant depends on its dependencies.
The two classes that use each other are termed as ‘coupled’. The coupling between classes are not binary — it’s either ‘tight’(strong) or ‘loose’(weak). These dependencies are always directional i.e.
Targaryens depend upon
Dragons but Dragons may not depend upon
Why dependencies are bad?
When there are many dependencies floating around the class, it leads to hard dependency problems — which are bad because of the following reasons
- Hard dependencies reduce the reusability
- Hard dependencies make it hard for testing
- Hard dependencies hinders code maintainability when the project scales up
When classes and methods are loosely or not coupled or not dependant on many things, it’s reusable nature increases. Reusability is one of the core commandment of object-oriented programming.
For testing, you will mock certain objects. But if there are so many dependencies within the method or the class, it will be hard to test. If a java class creates an instance of another class via the
new operator, then it cannot be used and tested independently from that class.
When your code cannot be tested properly and the components are not reusable and if your project continues to grow, it will be very difficult to maintain. Maintainability includes a lot of other factors, but as long as new developers in your team understands the system and makes the work of developers comfortable, you are good to go.
Types of Dependencies
Dependencies are of many types, the common ones are
- Class dependency
- Interface dependency
- Method/field dependency
- Direct and indirect dependency
And few more dependencies are there, which are not included here.
Class dependencies are the dependencies on classes. We have seen the class dependency example earlier, the constructor method
Targaryens depends on or needs the
Dragons class to invoke
Interface dependencies are the dependencies of the interfaces. The method
executePlan takes the interface
WarStrategy as the dependency. Where
WarDependency will be implemented by all the houses (Targaryens, Starks, Lannisters etc..)
#Method or Field Dependency
Method or field dependencies are dependencies on concrete methods or fields of an object. The following method takes a class object and the method
getKing() is the method dependency, which cannot be identified with method declaration.
#Direct and indirect dependency
Let me break this down with another example. Class
Targaryens are dependant on class
Starks for conquering the throne. But
Starks are dependant on other Kingdoms in the North say, class
Mormont — so now,
Targaryens are indirectly dependant on
Mormont and directly dependant on
If a java class creates an instance of another class via the
new operator, then it cannot be used and tested independently from that class and is called a dependency.
Dependencies are bad because it prevents the code reusability throughout the project and also makes the job of testing difficult — because of this it also hinders the code maintenance.
Dependencies are of many types like class, interface, method or field, direct and indirect etc..
On the next pitstop, we’ll be talking on the solution for this hard dependency problem — yes, you’re right : dependency injection. We’ll go through a real scenario, identify hard dependency and analyse it.
Dagger 2 for Android Beginners — DI part I
This story is the second part of the series, Dagger 2 for Android Beginners. If you did not read the previous one, you…
Plus, checkout my other stories.
Thank you for using your precious time to read this article. Liked it? Clap your 👏 to say “thanks!” and please share it to help others find this article.