Understanding the Dependency Inversion Principle

Of the five SOLID principles, the Dependency Inversion Principle is the one I took the longest to learn as an aspiring software developer. At a basic level, high-level modules should not “depend” or take their structure from lower-level modules. We do this to maximize decoupling.

By Sholmo Shalev

The following code is undesirable because the Forest class is tightly coupled to the tree classes, making it so that you need to change the tree class every time you add a new tree type. This makes extensibility incredibly difficult. Do not flame me in the comments, this is pseudocode

class MapleTree { int id; ... }
class OakTree { int id; ... }

class Forest {
    private: 
		    auto[] trees;
    public:
        addMaple(auto maple) { trees.add(maple); }
        addOak(auto oak) { trees.add(oak); }
		.
		.
		. // as we can see, we will need to add a new method for each tree type
}

We can change this to adhere to the DIP by just adding an extra layer of abstraction:

class interface i_Tree() {
	private
		int id;
}

class MapleTree { i_Tree { ... } }

class OakTree { i_Tree { ... } }

.
. 
. // now, the work is done at the implementation level, not the structural level!

class Forest() {
	private:
		i_Tree[] trees;
	public:
		Forest();
		addTree(i_Tree tree) { trees.add(tree); }
}

With this new structure, Forest now depends on the i_Tree interface, not on a concrete type. We only have to modify one class in our implementation, in stead of adding more methods to a superclass. If we wanted to have a PineTree class, we could add it and many other tree types without ever modifying our Forests class again. The work is done at an implementation level, not structural.

By Jeroen den Otter

From my classes, I have developed the opinion that some of the SOLID principles are redundant. For instance, appropriate application of the Open/Closed Principle would logically result in application of the Dependency Inversion Principle. Similarly, diligent application of the Single Responsibility Principle should make the Interface Segregation Principle obsolescent.

The Dependency Inversion Principle is a useful concept among the SOLID principles. It promotes decoupling in software design by requiring high-level modules to entirely remain independent of low-level modules. My initial example illustrated how the Forest class was tightly coupled to specific tree classes, making extensibility more complicated. By abstracting a layer through an interface like i_Tree, the Forest class can now operate independently of specific tree types, allowing for easy addition of new types like PineTree without altering the Forest class itself. This thought experiment helped me develop greater insight into the relationships among the SOLID principles and gave me a much more nuanced perspective on software design architecture.

Thank you to everyone who took time to talk with me about this subject this past week. I also found this this GeeksForGeeks and this ObjectOrientedDesign article to be the most helpful in understanding the topic.