Code360 powered by Coding Ninjas X Naukri.com. Code360 powered by Coding Ninjas X Naukri.com
Table of contents
1.
Introduction
2.
Definition of Dependency Inversion Principle
3.
Example of Dependency Inversion Principle Violation
4.
Fixing violation of Dependency Inversion Principle
5.
Tips for Applying Dependency Inversion Principle
6.
Benefits of using Dependency Inversion Principle
7.
Frequently Asked Questions
7.1.
How do we apply dependency inversion principle?
7.2.
What are some common pitfalls to avoid when applying the Dependency Inversion Principle?
7.3.
How does the Dependency Inversion Principle relate to the Open-Closed Principle?
8.
Conclusion
Last Updated: Mar 27, 2024
Medium

Dependency Inversion Principle in System Design

Author Suraj Pandey
0 upvote
Master Python: Predicting weather forecasts
Speaker
Ashwin Goyal
Product Manager @

Introduction

Do you know what the Dependency Inversion Principle is? It's a cool name for a simple idea that can make things easier and more flexible to change. Let us understand this with the example of a toy car.

A toy car that needs a battery to run. It's common to put the batteries inside the car, but changing them can be tough if we want to use a different kind of battery or if they run out.

But we can make it easier with something called the Dependency Inversion Principle. We could create a holder specifically for the battery that the car can connect to instead of keeping the battery inside the car. This way, we can easily change batteries or use a different type without disassembling the car.

Dependancy Inversioin Principle

So, the Dependency Inversion principle is like using a battery holder for a toy car, where we can easily change the battery without messing with the car. It makes things easier and more flexible!

By using the battery holder (abstraction) as an intermediary, the toy car (high-level module) can operate without directly relying on the battery (low-level module). This makes it easy to swap batteries without disturbing the car.

Definition of Dependency Inversion Principle

One of the SOLID design principles used in software development is the Dependency Inversion Principle (DIP). It suggests that when designing software systems, high-level modules should not depend directly on low-level modules. Instead, both high-level and low-level modules should depend on abstractions or interfaces. 

Abstractions play an important role in the Dependency Inversion principle, which helps create a flexible and modular software system by separating high-level modules from low-level modules.

Get the tech career you deserve, faster!
Connect with our expert counsellors to understand how to hack your way to success
User rating 4.7/5
1:1 doubt support
95% placement record
Akash Pal
Senior Software Engineer
326% Hike After Job Bootcamp
Himanshu Gusain
Programmer Analyst
32 LPA After Job Bootcamp
After Job
Bootcamp

Example of Dependency Inversion Principle Violation

A common violation of the DIP in C++ is when a high-level module depends on a low-level module via a concrete class rather than an abstraction. 

For example, consider the following code:

#include <iostream>
#include <vector>

class Database {
public:
    void insertData(const std::string& data) {
        std::cout << "Inserting " << data << " into database." << std::endl;
    }
};

class DataProcessor {
public:
    void processData(const std::vector<std::string>& data, Database database) {
        for (const auto& d : data) {
            database.insertData(d);
        }
    }
};

int main() {
    std::vector<std::string> data {"data1", "data2", "data3"};
    Database database;
    DataProcessor processor;
    processor.processData(data, database);
    return 0;
}

 

In this example, the DataProcessor class depends on the Database class via a concrete class, rather than an abstraction. This makes the DataProcessor tightly coupled to the Database class, making it difficult to replace the Database class with a different implementation, or to test the DataProcessor class in isolation.

Fixing violation of Dependency Inversion Principle

To fix this violation of the DIP, we can introduce an abstraction for the Database class, such as an interface or abstract base class, and have the DataProcessor depend on this abstraction rather than the concrete Database class. 

For example:

#include <iostream>
#include <vector>

class IDatabase {
public:
    virtual void insertData(const std::string& data) = 0;
    virtual ~IDatabase() {}
};

class Database : public IDatabase {
public:
    void insertData(const std::string& data) override {
        std::cout << "Inserting " << data << " into database." << std::endl;
    }
};

class DataProcessor {
public:
    void processData(const std::vector<std::string>& data, IDatabase& database) {
        for (const auto& d : data) {
            database.insertData(d);
        }
    }
};

int main() {
    std::vector<std::string> data {"data1", "data2", "data3"};
    Database database;
    DataProcessor processor;
    processor.processData(data, database);
    return 0;
}

 

In this modified code, the DataProcessor class depends on the IDatabase abstraction, which is implemented by the Database class. This allows us to replace the Database class with a different implementation, such as a mock database for testing, without changing the DataProcessor class. This also makes the DataProcessor class more modular and easier to test in isolation.

Tips for Applying Dependency Inversion Principle

Here are the tips for implementing DIP in our code:

  1. Identify high-level modules: First, we need to find the main modules in our software that manage or coordinate other modules or tasks. These modules are usually more general and abstract.
  2. Identify low-level modules: Next, we should identify the modules in our software that perform specific tasks or functionalities in a more focused and specialised way. These modules often rely on abstractions provided by higher-level modules to work properly.
  3. Define abstractions: After identifying the high-level and low-level modules, we need to define abstractions that allow these modules to interact with each other. An abstraction can be an interface or abstract class that outlines the methods or properties needed for communication.
  4. Make higher-level modules depend on the abstraction: To follow DIP, we must change the way high-level modules communicate with low-level modules. Instead of directly depending on lower-level modules, high-level modules should depend on the common interface or abstract class.

Benefits of using Dependency Inversion Principle

Here are the benefits of using the Dependency Inversion Principle in our code:

  • Increased flexibility: DIP creates a more adaptable design that can handle changes more easily.
  • Improved maintainability: DIP makes our code easier to maintain and update, as changes to one module do not require changes to other modules that depend on it.
  • Better testability: DIP makes it easier to write unit tests for our code, as it allows us to isolate and test individual modules without worrying about their dependencies.
  • More modular code: DIP promotes modular code design, which is easier to understand, reuse, and extend.


Overall, the dependency inversion principle can help us to create more flexible, maintainable, testable, modular, and collaborative software designs that can adapt to changing needs and scale over time.

Frequently Asked Questions

How do we apply dependency inversion principle?

To implement the Dependency Inversion principle, we can use techniques such as abstraction, interfaces, and design patterns such as Factory, Abstract Factory, and Dependency Injection.

What are some common pitfalls to avoid when applying the Dependency Inversion Principle?

Some common pitfalls to avoiding applying the Dependency Inversion Principle are creating too many layers of abstraction, introducing unnecessary complexity, and violating the Single Responsibility Principle.

How does the Dependency Inversion Principle relate to the Open-Closed Principle?

The Dependency Inversion Principle and the Open-Closed Principle are both part of the SOLID principles of software design. The Open-Closed Principle suggests that software entities should be open for extension but closed for modification, while the Dependency Inversion Principle suggests that high-level modules should depend on abstractions rather than low-level modules.

Conclusion

In this blog, we learn about the Dependency Inversion Principle (DIP), one of the principles of SOLID, which focuses on developing modular and loosely coupled systems. We explained that DIP is the principle that recommends using abstractions instead of low-level modules when creating dependencies for high-level modules.

We then explored an example of a violation of the Dependency Inversion Principle, where a high-level module directly depended on a low-level module, leading to a tightly coupled and inflexible system.

To fix this violation, we discussed how introducing an abstraction (such as an interface) that both the high-level and low-level modules depend on can help create a more flexible and maintainable system.

We also provided some tips for applying the Dependency Inversion Principle, such as avoiding creating too many layers of abstraction and ensuring that abstractions are well-defined.

Finally, we highlighted some benefits of using the Dependency Inversion Principle, including better modularity, increased flexibility, and easier maintenance.

You can also consider our System Design Course to give your career an edge over others.

We value your thoughts and would love to hear your feedback in the comments section below.

🌟 Wishing you the best of luck on your system design journey! 🚀

Previous article
Interface Segregation Principle in System Design
Live masterclass