Dependency Inversion Principle in C++: SOLID as a Rock

Dependency Inversion Principle(in C++) is the fifth and last design principle of a series SOLID as a Rock design principles. The SOLID design principles focus on developing software that is easy to maintainable, reusable, and extendable. In this article, we will see an example code with the flow and correct it with help of DIP. We will also see guidelines and benefits of DIP at the ens of the article.

By the way, If you haven't gone through my previous articles on design principles, then check out the following quick links:

Interface Segregation Principle | SOLID as a Rock

Interface Segregation Principle in C++ is the fourth & by far the simplest design principle of a series SOLID as a Rock design principles. The SOLID design principles focus on developing software that is easy to maintainable, reusable & extendable. In this article, we will see a code violating ISP, a solution to the same code, guideline & benefits of ISP.

By the way, If you haven't gone through my previous articles on design principles, then below is the quick links:

SOLID code, the Silver Bullet

SOLID is one of those words we developers throw around us, implying some deeper meaning, hopefully helping us to create better software systems. It should be second hand nature to all (OO) developers, but unfortunately is often misunderstood, or used to defend a decision, based upon flawed logic. Hence, in this article, I will try to "dumb it down" and use analogies for each of its 5 items, in an attempt at making it more easily understood, to avoid confusion.

Single Responsibility Principle

The "S" I'm solid implies that each class should only do one thing. It often helps to break down your flow into verbs to make sure you follow this principle. For instance, imagine you have a task scheduler, that should implement the ability to create tasks for execution at some point into the future. Maybe you want it to have the ability to persist tasks, in case the process is recycled, without dropping tasks. Imagine Hangfire here as an example. Well, ask yourself how many verbs you have in the above feature requirement, and then try to group them into related actions. I could find the following.