DEPENDENCY INVERSION PRINCIPLE

What is DIP?

At first, this concept seems a bit difficult to grasp, but after some struggling and council from our coach, we were able to form a better understanding. Let's start off with the basics.

The Dependency Inversion Principle refers to "a specific form of decoupling software modules."

"Well, what is decoupling?" you might ask. From what we gathered, coupling is the measure of the strength of the relationship between two routines or modules. Decoupling, then would seem to be the reversal of that, in which the relationship between two routines or modules becomes less crucial and thus causes each to depend less on the other.

In the Dependency Inversion Principle:

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.

High-Level Classes --> Abstraction Layer --> Low Level Classes

(cited from Wikipedia page on DIP)

A couple notes on this. "A module is a unit that contains everything necessary to execute only one aspect of the desired functionality." A high-level class is more or less a class which brings other classes into it.

An abstraction can be considered a high-level class, except it is less specific and can allow lower classes to inherit from it without the high-level classes depending on low-level classes.

DIP reduces risk by reducing need for changes. In order to do this, DIP relies on a concept instead of an implementation.

Example code:

Our understanding of this information may not be as accurate as we would like it to be. However, we welcome suggestions for any improvements on the post or insight into DIP.