I just got an understanding of what is dependency injection!! I was hearing Dependency Injection from my colleagues and all, and I was stumbled!! what actually it is? Well now I say that’s a real piece of cake !!!.
The phrase “Dependency Injection” may sound intimidating. But as when we look closer we will realize that it’s not complex as it sounds .And by applying these DesignPattern(DependencyInjection is_a DesignPattern). to your code, then it become significantly easier to understand and easier to extent and test. Am quoting an example from a text here through which one can easily understand what actually it is.
Consider a Knight class.
- package com.springaction.knights;
- public class DamselRescuingKnight implements Knight {
- private RescueDamselQuest quest;
- public DamselRescuingKnight() {
- quest = new RescueDamselQuest();
- }
- public void embarkOnQuest() throws QuestException {
- quest.embark();
- }
- }
In the above snippet you can see DamselResuceKnight creates it’s on quest , a RescueDamselQuest(), within the constructor (LOC – 4&5).This actually makes a DamselRescuingKnight tightly coupled to a RescueDamselQuest() and it severly limits the knight’s quest-embarking repertoire. Actually it can rescue a Damsel yea it is supposed to that, but what else it can do? Nothing but simply sit.
And also when you get familiar with testing, you will find it difficult to test such a piece of code.(unitTests). In writing test, the scenario here is you got to assert that quest’s embark(); method is called when the knight’s embarkOnQuest() is called, the code is supposed to do so, But there is no clear way to test that here, so the DamselRescuingKnight will remain untested.
Here comes the Dependency Injection(DI). With DI, objects are given their dependencies at creation time by some third party that coordinates each object in the system. Objects aren’t expected to create or obtain their dependencies – dependencies are injected into the objects that need them.
Illustrating DI with the below code snippet
Consider a class BraveKnight and see that BraveKnight is ready and flexible enough to take any Quest!!
- package com.springaction.knights;
- public class BraveKnight implements Knight {
- private Quest quest;
- public BraveKnight (Quest quest) {
- this.quest = quest; <————- //Here the quest is being injected
- }
- public void embarkOnQuest() throws QuestException {
- quest.embark();
- }
- }
As in the above snippet unlike DamselRescueKnight, BraveKnight doesn’t create his own quest. Instead he is given a quest at the construction time as a constructor argument.This is a type of DI and is known as Constructor Injection.
The quest he’s give as type Quest, is an interface that all quests implement. So the BraveKnight could embark on a RescueDamselQuest, a SlyDragonQuest , or any other Quest implementation he is given. The point here is that BraveKnight isn’t coupled to any specific implementation of Quest.It doesn’t matter to him what kind of quest he is asked to embark upon.
Heap & Sharp 