You might be thinking, the second article in a week! I know! Doesn’t sound at all like me. This is what happens when the year is ending and you remember all your due tasks that need completion. And the upcoming tasks for the new year make you excited and you start freeing yourself up for them. So, here goes my last article in the SOLID series, on the last day of the year 2021. If you haven’t read the previous article in the series, please read it here — Interface Segregation Principle.
Who doesn’t want a reusable and loosely coupled piece of software? If you do too, the D in SOLID is here to assist you. Robert C. Martin describes the Dependency Inversion Principle (let’s call it DIP) as:
- High-level modules should not depend on low-level modules. Both should depend on abstractions (e.g., Interfaces).
- Abstractions should not depend on details. Details (concrete implementations) should depend on abstractions.
So, basically, if there is an Object A dependent on Object B, Object A should not refer to Object B directly, but via Abstraction. i.e. there should be an abstraction layer (Interface or Abstract Class) between Object A and B. Object A should refer to that abstraction, and object B should inherit from that abstraction. Confused why do we need this? Let's understand it by helping a small Momos shop this time. Who doesn’t want steaming hot momos in this cold weather? 🙂
The specialty of this Cafe is that it's fully automated, having Mr. Robot as its chef. So let's help Mr. Robot in making some hot Momos.
We will start with the low-level class ‘Momos’, responsible for steaming these momos.
Now, Chef, the High-level class will use the above Momos class, to steam some hot momos.
Now, just call our chef and it will serve you some tasty Momos. But I guess we know what the issue is here. Our high-level class — ‘Chef’ is directly dependent on the low-level class ‘Momos’. And with people getting health conscious these days, we might get a demand for some hot steamy vegetables soon. But we have wired the chef directly to just steam momos. 😐
Now to add steamed vegetables to the menu we need to do the following changes to the Chef class:
Just think about the modifications that we might need in Chef class, every time we want to steam something new.
Let’s follow the Dependency Inversion Principle now, according to Uncle Bob, and improve our flawed design.
What if we create a Steamer Interface (abstraction layer) between Chef and Momos. That way, Chef will directly interact with only the abstraction layer — Steamer and we can add as many steaming options as we want.
Now, according to uncle Bob, let Momos (Low-level) class Inherit the abstraction — Steamer.
And let Chef (High-level) class, refer to the abstraction — Steamer.
This way we can add as many low-level steamer classes as we want (Vegetables, Bow Buns, etc.), without worrying about changing the high-level Chef class.
So basically, we made our code loosely coupled, easy to maintain, extend and reuse, just by following the Dependency Inversion Principle.
I hope the article helped you understand this simple, yet powerful Principle. Please use it in your projects and let me know how it helped you write some ‘Good Code’. 😊
This completes my series on SOLID principles. I hope you had as much fun reading the articles as I had in writing them.
Happy Learning!
