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

Question

In past couple of days, I have read about quite a lot about dependency injection/inversion of control/inversion of dependency. I think that, now my understanding of the concept is much better. But I still don't get the following from wikipedia:

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

I understand the part of High-level modules should not depend on low-level modules. But, I am confused about abstractions and details.Can someone please simplify them for me. Thanks.

Answer 1

It means that if the details change they should not affect the abstraction. The abstraction is the way clients view an object. Exactly what goes on inside the object is not important. Lets take a car for example, the pedals and steering wheel and gear lever are abstractions of what happens inside the engine. They do not depend on the details though because if someone changes my old engine for a new one I should still be able to drive the car without knowing that the engine changed.

The details on the other hand MUST conform to what the abstraction says. I would not want to implement an engine that suddenly causes the brakes to double the speed of the car. I can re-implement brakes any way I want as long as externally they behave the same way.

Answer 2

Example of the abstraction and the details: a stream provides an interface to read a token. That's an abstraction.

A stream implementation of the stream is bound to implement the interface defined by the abstraction: that's why it depends on it. If it provides a different interface (one to read 100 characters at a time) it cannot claim to implement the same abstraction.

Answer 3

Think of the work you need to invoke, and how far away that is from where you are currently coding. There is a spectrum there; your position on it represents the amount of work you need to do to invoke that functionality.

Abstractions move that position closer to the code you are writing. For example, if you have to call a web service, you can either 1) write the calling code directly where you need to use it, or 2) put those details behind an abstraction (such as an interface).

In this case, #1 puts you closer to the web service on the spectrum, while #2 keeps you closer to your work. Abstraction can be said to be a measure of how far you have to stretch your mind to comprehend the work you need done.

What this means is that every piece of work can be abstracted so that it is "closer" to the code using it. By having both sides of an operation depend upon abstractions, they both become easier to understand, and neither side has to harbor knowledge of the gap between them - that is the job of the abstraction.

Wow, that was abstract.