ependency nversion rinciple in C++ is the fifth & 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 & extendable. In this article, we will see an example code with the flaw & correct it with help of DIP. We will also see guideline & benefits of DIP inclosure of the article. D I P By the way, If you haven’t gone through my previous articles on design principles, then below is the quick links: RP – Single Responsibility Principle S CP – Open/Closed Principle O SP – Liskov Substitution Principle L SP – Interface Segregation Principle I IP – Dependency Inversion Principle D The code snippets you see throughout this series of articles are simplified not sophisticated. So you often see me not using keywords like override, final, public(while inheritance) just to make code compact & consumable (most of the time) in single standard screen size. I also prefer struct instead of class just to save line by not writing “public:” sometimes and also miss , constructor, , prefix std::, deleting dynamic memory, intentionally. I also consider myself a pragmatic person who wants to convey an idea in the simplest way possible rather than the standard way or using Jargons. virtual destructor copy constructor Note: If you stumbled here directly, then I would suggest you go through first, even if it is trivial. I believe it will encourage you to explore more on this topic. What is design pattern? All of this code you encounter in this series of articles are compiled using C++20(though I have used features up to C++17 in most cases). So if you don’t have access to the latest compiler you can use which has preinstalled boost library as well. Modern C++ https://wandbox.org/ Intent 1. High-level modules should not depend on low-level modules. Both should depend on abstractions. 2. Abstractions should not depend on details. Details should depend on abstractions. Above lines might seem cryptic at first but don’t stick here keep going. You will get it by example. What are the High-level & Low-level modules? : which is more abstract in nature & contain more complex logic. These modules orchestrate low-level modules in our application. : more specific & individual to components focusing on details & smaller parts of the application. These modules are used inside the high-level modules. High-level modules describes operations Low-level modules describes implementations Motivation: Violating Dependency Inversion Principle parent, child, sibling }; m_name;
}; <tuple<Person, Relationship, Person>>     m_relations; {
        m_relations.push_back({parent, Relationship::parent, child});
        m_relations.push_back({child, Relationship::child, parent});
    }
}; Research( Relationships &relationships) { ( &&[first, rel, second] : relationships.m_relations) { (first.m_name == && rel == Relationship::parent) << << second.m_name << ;
        }
    }
}; {
    Person parent{ };
    Person child1{ };
    Person child2{ };

    Relationships relationships;
    relationships.add_parent_and_child(parent, child1);
    relationships.add_parent_and_child(parent, child2);

    Research _(relationships); EXIT_SUCCESS;
} enum { class Relationship { struct Person string { struct Relationships // Low-level <<<<<<<<<<<<------------------------- vector void add_parent_and_child ( Person &parent, Person &child) const const { struct Research // High-level  <<<<<<<<<<<<------------------------ const for auto // Need C++17 here if "John" cout "John has a child called " endl int main () "John" "Chris" "Matt" return When later on the container of Relationships changes from vector to set or any other container, you need to change in many places which isn’t a very good design. Even if just the name of data member i.e. Relationships::m_relations changes, you will find yourself breaking other parts of code. As you can see Low-level module i.e. Relationships directly depend on High-level module i.e. Research which is essentially a violation of DIP. Solution: Example of Dependency Inversion Principle in C++ Rather we should create an abstraction and bind Low-level & High-level module to that abstraction. Consider the following fix: <Person> find_all_children_of( &name) = ;
}; RelationshipBrowser { <tuple<Person, Relationship, Person>>     m_relations; {
        m_relations.push_back({parent, Relationship::parent, child});
        m_relations.push_back({child, Relationship::child, parent});
    } <Person> find_all_children_of( &name) { <Person> result; ( &&[first, rel, second] : m_relations) { (first.name == name && rel == Relationship::parent) {
                result.push_back(second);
            }
        } result;
    }
}; Research(RelationshipBrowser &browser) { ( &child : browser.find_all_children_of( )) { << << child.name << ;
        }
    } }; { struct RelationshipBrowser virtual vector const string 0 : struct Relationships // Low-level <<<<<<<<<<<<<<<------------------------ vector void add_parent_and_child ( Person &parent, Person &child) const const vector const string vector for auto if return { struct Research // High-level <<<<<<<<<<<<<<<---------------------- for auto "John" cout "John has a child called " endl //  Research(const Relationships& relationships) //  { //    auto& relations = relationships.relations; //    for (auto&& [first, rel, second] : relations) //    { //      if (first.name == "John" && rel == Relationship::parent) //      { //        cout << "John has a child called " << second.name << endl; //      } //    } //  } Now no matter, the name of container or container itself changes in Low-level module, High-level module or other parts of code which followed DIP will be in-tact. The Dependency Inversion Principle (DIP) suggest that the most flexible systems are those in which source code dependencies refer only to abstractions, not to concretions. This is the reason why most experienced dev uses STL or library functions along with generic containers. Even using an auto keyword at appropriate places may help in creating generic behaviour with less fragile code. There are many ways you can implement DIP, as long as C++ concerns most people use static polymorphism(i.e. unless they need dynamic one), , , , etc. CRTP template specialization Adapter Design Pattern type-erasure Yardstick to Craft Dependency Inversion Principle(DIP) Friendly Software in C++ If you find enforcing DIP difficult then just design abstraction first & implement your high-level module on the bases of abstraction. Without having any knowledge of the low-level module or its implementation. Because of this process DIP is also known as . Coding To Interface Keep in mind that all Low-level-modules/ adhere to the . This is because the Low-level-modules/ will be used via the abstract interface, not the concrete classes interface. subclasses Liskov Substitution Principle subclasses Benefits Reusability Effectively, the DIP reduces coupling between different pieces of code. Thus we get reusable code. Maintainability It is also important to mention that changing already implemented modules is risky. By depending on abstraction & not on concrete implementation, we can reduce that risk by not having to change high-level modules in our project. Finally, DIP when applied correctly gives us flexibility and stability at the level of the entire architecture of our application. Our application will be able to evolve more securely and become stable & robust. Conclusion As you can see we took a basic example of code & converted it into a reusable, flexible & modular piece of code. If I would have to summarize DIP in simple & short sentence then it would be like: . D o not use the concrete object directly unless you have a strong reason to do so. Use abstraction instead DIP trains us to think about classes in terms of behavior, rather than construction or implementation. Previously published at http://www.vishalchovatiya.com/dependency-inversion-principle-in-cpp-solid-as-a-rock/

Different

Keep

Mind

www.vishalchovatiya.com

Read My Stories

Too Long; Didn't Read

In your car, at home, or at work — Bosch technology shapes many areas of life.

SOLID Design: Dependency Inversion Principle in C++

Too Long; Didn't Read

Companies Mentioned

Vishal Chovatiya

About Author

TOPICS

THIS ARTICLE WAS FEATURED IN...

SOLID Design: Dependency Inversion Principle in C++

Too Long; Didn't Read

Companies Mentioned

Vishal Chovatiya

About Author

TOPICS

THIS ARTICLE WAS FEATURED IN...

RELATED STORIES