paint-brush
Dependency Inversion Principleby@vadim-samokhin
4,165 reads
4,165 reads

Dependency Inversion Principle

by Vadim Samokhin
Vadim Samokhin HackerNoon profile picture

Vadim Samokhin

@vadim-samokhin

Aspiring object-thinker

May 11th, 2018
Read on Terminal Reader
Read this story in a terminal
Print this story
Read this story w/o Javascript
Read this story w/o Javascript
tldt arrow

Too Long; Didn't Read

This is the fifth, and the last post on <a href="https://hackernoon.com/solid-principles-530b2cc2badf" target="_blank">SOLID</a> principles. Check the previous one, Interface Segregation Principle, <a href="https://medium.com/@wrong.about/interface-segregation-principle-bdf3f94f1d11" target="_blank">here</a>.

People Mentioned

Mention Thumbnail

Robert Martin

@rbrtmrtn

featured image - Dependency Inversion Principle
1x
Read by Dr. One voice-avatar

Listen to this story

Vadim Samokhin HackerNoon profile picture
Vadim Samokhin

Vadim Samokhin

@vadim-samokhin

Aspiring object-thinker

Learn More
LEARN MORE ABOUT @VADIM-SAMOKHIN'S
EXPERTISE AND PLACE ON THE INTERNET.

Decoupling, modularisation, and clean architecture

This is the fifth, and the last post on SOLID principles. Check the previous one, Interface Segregation Principle, here.

Definition

As usual, I start with Wikipedia citation:


A. High-level modules should not depend on low-level modules. Both should depend on abstractions. B. Abstractions should not depend on details. Details should depend on abstractions.

There is no such division on A and B items in original Robert Martin’s book. Wikipedia has it, but unfortunately, it doesn’t elaborate on why is it so. Besides, it’s not clear what is assumed by high-level and low-level modules. I think it deserves some notes.

Objects exist to carry out some work. They can do it themselves, or with a help of some other objects. Chances are that those “helper” objects represent some useful abstraction, that is, there are more than one classes capable of implementing the certain contract. So I want to reflect this fact in code:



class A{private $b;

**public function** \_\_construct(B $b)  
{  
    $this->**b** \= $b;  
}  

}

Object $b is an implementation detail for object of class A. Thus, interface B is, or, however, should be defined in terms of A, and in the same package as A. So that’s why any object implementing interface B is considered a lower-level with respect to A.

So according to its definition, Dependency Inversion Principle is about two things: decoupling and correct modularisation.

Let’s elaborate a bit further

At good old times, when nobody used interfaces, objects were instantiated right inside the classes that used them. So they depended directly on those implementation details (Figure 1 in the image below). Today we value decoupling and polymorphism, so we use interfaces to make our dependencies explicit. This is not Dependency Inversion Principle still, this is just a Dependency Injection. In order for it to become an inversion, we must claim that consumer class owns his dependency abstractions. Now, modules representing an implementation detail, depend on more abstract modules (Figure 2 on an image below). Thus, Dependency Inversion Principle reversed the dependency direction between a consumer code and dependency implementation code.

image

Source: en.wikipedia.org/wiki/Dependency_inversion_principle

Evolution to Clean Architecture

As a special case, and further evolution, DIP states that business-logic should not directly depend on technical details. Instead, it should define an interface that it owns, so that all the implementation code (for example, database queries, http communication, email sending and pretty much any infrastructure logic) depends on this central layer — policy layer. For me it sounds like a harbinger of a Clean Architecture:

image

Final thoughts

Well, this principle basically boils down to good old loose coupling thing, which has been around for at least fifty years. And David Parnas has already said everything that was necessary on how to define modules. I guess the only advantage of Dependency Inversion Principle is that it’s way less ambiguous than the others in SOLID family.

L O A D I N G
. . . comments & more!

About Author

Vadim Samokhin HackerNoon profile picture
Vadim Samokhin@vadim-samokhin
Aspiring object-thinker

TOPICS

THIS ARTICLE WAS FEATURED IN...

Permanent on Arweave
Read on Terminal Reader
Read this story in a terminal
 Terminal
Read this story w/o Javascript
Read this story w/o Javascript
 Lite
Github
Github

Mentioned in this story

profiles
X REMOVE AD