A Guide To Dependency injection

Dependency injection is is a type of creational design pattern which implement the concept of Inversion of control (A subset of Inversion of Control) . Objects required are directly injected to the class instead of creating an object within the class. Dependency injection makes the code loosely coupled and using this we can design systems which are highly scalable given in a micro service environment. It also helps in achieving SOLID’s dependency inversion and single responsibility principle to a greater extend.

Apparently if java classes are independent of each other it increases the possibility of reusing them. It also helps a-lot in testing since each component can be tested independently. If a java class uses “new” operator to create instance of other class , it would achieve a hard dependency. Another great advantage is that it allows client the flexibility of being configurable.

Consider a scenario of building a mobile from scratch.In realtime most of the organisations wont be building each and every component , rather that would be assembled from various other companies. In this case let’s assume Samsung is proving us the display component of our mobile.
Inside the Mobile class , when we declare object samsungDispaly like the following code , it kind of makes the code tightly coupled and the all the display component would be dependent on Samsung, which makes the code highly dependant and not scalable.

class Mobile {
Samsung samsungDispaly = new Samsung();

Instead , if you inject an object of display to the Mobile class and if all the property of that object is defined in its own class. Here In this case the code becomes less dependent ,and loosely coupled . Near future if we like to use the display of xiaomi Instead of Samsung , it could easily be done by injecting an object of xiaomi.

Another important advantage of dependency injection is the fact that the system would achieve testability. Writing unit test cases or any low level test cases are comparatively easy when classes / components are less dependent. Since each component are independent and loosely coupled , testes can be done by mocking techniques.
Ex : While testing Mobile , you probably would’t need to test SamsungDisplay or xiaomiDisplay , since it’s already been tested independently.

class Samsung implements Display{
// lines of code

class Mobile {

Display samsungDispaly;


In spring framework in order to achieve Dependency injection we could simply use a @Autowired Tag. In the above piece of code — class Mobile is asking for a Display and I do have a Display component there, so we are connecting both of them. You can read more concrete examples of its use in Spring framework here.

Couple of disadvantages are :

  1. It Requires more development effort upfront.
  2. Effect of changes are known at runtime rather than compile time , If overused without proper planning may leas to maintenance issue.
  3. Reduces code readability. Since DI uses large number of classes , tracing those can get difficult at times.



Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store