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.

An interesting case where an abstraction depends on details is when you define an interface that inherits from IDisposable. Take a look at the following abstraction:

public interface ICustomerRepository : IDisposable
{
    Customer GetById(Guid id);
    Customer[] GetAll();
}

Note: IDisposable is an interface specific for .NET, but you can easily imagine your interface containing a Dispose method itself instead of inheriting from such interface.

It might look convenient for the ICustomerRepository to implement IDisposable. This way any caller can dispose the repository and this way the implementation can dispose the connection or unit of work that it uses internally.

The interface however is now written with a certain implementation in mind, since it s not obvious at all that all ICustomerRepository implementations would need to clean up any resources. The interface therefore leaks implementation details and therefore violates the Dependency Inversion Principle.

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.

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.