In this post you will learn what Dependency Injection is, why it would be useful and how to implement it.
The examples will be written in C# and published into my GitHub.
I chose C# because it’s a fairly popular language and will (hopefully) be understood by anyone from any language.
Let’s get right in.
What is Dependency Injection
Dependency Injection is a complex sounding name to a pretty simple concept.
It’s a programming technique (also sometimes called design pattern) that helps implementing Inversion of Control.
It is used to pass a dependency (class that needs to be called) onto the class we’re coding, promoting loose coupling and allowing said dependency to be changed at runtime. (for instance by user input)
Suppose we have a class that looks like this:
You can clearly see that this isn’t dependency “injectable”, since when calling this method, we can’t specify which payment method to use, we’re forced to use Credit Card.
What would be an example of Dependency Injection then?
In that case, we can change which payment method the method will use at runtime, by passing an implementation of IPaymentMethod via parameter.
We could call it like this:
Why would we want this?
There are quite some advantages of using DI, here is a (possibly) non-exhaustive list:
- Easier to unit test
- By allowing us to change the dependency from the “outside” (when calling it), we can change its dependency to a mocked one.
- It’s a good alternative to the Singleton pattern
- Static is usually seen as evil, and Singleton is no exception, being regarded as an anti-pattern.
- Easier to maintain
- Suppose you are using that first PersonExample in 50 different places, now imagine that you want to introduce a different IPaymentMethod, but only in 20 of those… How would you do that?
- If you’re using Dependency Injection then it’s way easier, you would still need to change the code in 20 different places but it’s not as bad as when not using it.
- If you were doing as the first, non-DI, example then you would probably need to pass a boolean or enum that would determine which payment method to use, in all those places, yikes!
- Decoupling from the class and its dependency
- This is closely related to the previous, basically it allows us to re-use the class we’re writing more often, by making our class not be attached to the Dependency we’re using.
How to implement it?
You can find the code at my GitHub: https://github.com/LegendL3n/Inversion-of-Control.
Keeping in mind that in the GitHub example I’m passing the dependency via constructor.
However, you can just pass it in a method via parameter, in case only such method needs the dependency, or it could be a setter, in case the dependency is expected to change throughout the object’s lifecycle.
If you need the dependency in multiple places, you could either make the Person class implement an interface, that forces it to implement a method to inject the payment method on, or extend a class, that forces it to get from the constructor and/or inherits a setter for that.
Hopefully everything was clear, see you in the next one 😉.