Dependency Injection

Today we are going to talk about a very important topic “Dependency Injection”.  I’ve heard Dependency Injection is confusing for most of the developers out there hence they don’t use it.

Dependency Injection is a simple concept and it will save your time in future. believe me 🙂

What is Dependency Injection (DI) ?

DI is a design pattern that is used to develop loosely coupled systems. In other words, this helps us to create classes that are loosely coupled and separate the logic dependency.
You can apply this to any OOP language. I have used C# for the demonstration. This way, you can write cleaner and re usable code.

Why DI ?

DI is very helpful when it comes to the unit testing and maintainability. You don’t want to write smelly code do you? Your code should be generic (reusable) , testable and maintainable. Once you learn to implement DI, you will not go to the old (bad) way 🙂 With DI you can achieve re-usability, maintainability and write testable code.


First lets take a simple tightly coupled scenario. Please refer to the below figure.


You have a class called “Employee” and it’s “process” method creates an object of “SavetoText” class and calls the “Save” method. Then the “Save” method saves the data to a Text file. Everything works fine. Today you are also taking the same approach probably.
Now, What is wrong with this code? you will not be able to point this today. But tomorrow when your boss asks you to save the data in a database instead of a text file, you will be thinking, Oh now I need to add a new method in to the “SavetoText” class and change the Employee class also. This looks simple here. But imagine of you have 100 classes and 10 people are working on the project . To implement this , you will need to touch and change hell lot of code.

This is a classic example of a tightly coupled example.

Lets see how we can change the above smelly code with DI.

First thing you need to understand is, your “Employee” class is now highly dependent on “SavetoText” class. We need to break this dependency. So then your “Employee” class will be independent of saving logic. This is where the interface comes in to the picture.

Now lets create an interface.


This simple interface will be the contract for saving. All your saving classes should implement this interface. Please refer to the below figure.


Now, the “SavetoText” class implements the “ISave” interface.  Your Employee class has an constructor that accepts an Object implements the “ISave” interface. Also “Employee” class has a private property to get the “ISave” object which is happening in the constructor.

As you can see, now the dependency of “SavetoText” object is broken. We are injecting it to the “Employee” class’s constructor.  So tomorrow if you boss asks you to save in the database, you just need to add a new class and inject it. That’s it. Please refer to the below example.


I have created a new class for saving the data to a database and implemented the “ISave” interface, then Injected it to the Employee class’s constructor. With this approach, you can write thousands of saving classes without even touching the “Employee” class.

If you have questions or doubts, please leave a comment.

Thank you.

About Kasun Koswattha

Kasun Koswattha
Kasun Koswattha (Kasun) a .NET Engineer | a Gamer from United States. Join with the c2k community to share your knowledge. Like and share...


  1. Surath Jayetileke

    Thanks. This was of great help!

  2. Thanks a lot, Really easy to understand by the way you simply explain it.

Leave a Reply