Second statement of the Dependecy Inversion Principle

Question

The second statement of the Dependecy Inversion Principle states:

"Abstractions should not depend upon details. Details should depend upon abstractions."

What does 'details' mean in this context?

• Steven: If you fail to adhere to this second part of the definition, you are implementing leaky abstractions.

Answer 1

I prefer think about abstractions like "what a result I want to get", and about details like "how I want to get a result".

The principle means that details changing (f.e. a lifetime of object, an algorithm, a precision, etc.) doesn't change abstractions.

Answer 2

Abstractions can be behavioral aspects which can be utilized by consuming code in terms of interfaces. Any class/code, which is high level or low level would communicate using abstraction and not using operators. These classes are defined as "details".

Answer 3

My understanding of this is that it relates closely to the first principle that "High-level modules should not depend on low-level modules. Both should depend on abstractions". The implementation of this will generally take the form of an interface that both your high and low level classes use to talk to each other.

Well, this is basically already following the second principle because our details, being the concrete implementations of the classes that are using that interface are now depending on an abstraction, being the interface that the classes are now using.

Further the abstractions are now no longer dependent on the classes themselves because they now live behind the interface that both the classes have implemented and so are free to change (other than the signatures of course) without making changes to the details of the concrete implementations necessary.

I don't think I've been as clear as I like but I hope this helps.

Answer 4

Let me try to share my vision

I believe this term is normally used in a context of a relationship between 2 components A and B let's say (A is using B, A -> B). So just 'abstraction' makes no sense for me. What makes sense is something like 'Abstraction of B from A's point of view'

My attempt to build a strict definition (more or less):

If A uses B then abstractions of B from A's point of view is the minimal and sufficient set of info A must know about B to use it properly.

• Minimal: if your abstraction contains smth A can omit - your module A is using B's details. This is bad. B's author(s) may decide to change it which will result in a broken communication.
• Sufficient: if A can't use B properly without something that's not a part of your 'abstraction', that means it should become a part of your abstraction

I believe that the primary goal of this terms (details, abstraction) is a quick way to mention either something you can (details) change without breaking A->B communication or something you can not change that easy (abstraction) in a proper A -> B usecase.