While some central concepts in the realm of object-oriented design are generally harder to digest at first, such as separation of concerns and implementation switching, more intuitive and untangled paradigms on the other hand are simpler, like programming to interfaces. Unfortunately, the DIP's formal definition is surrounded by a double-edged curse/blessing that often makes programmers gloss over it, as in many cases there's an implicit assumption that the principle is nothing but a fancy expression for the aforementioned "programming to interfaces" commandment.

He talks about how decoupling your code and working against interfaces is only part of the equation. The other half is the actual "inversion" part of the process - the ownership that the high-level modules must have over the abstractions. He illustrates with an example, a storage module that is highly dependent on a Serializer. Using the DIP principle, he turns this around and refactors his storage class to take in an Encoder object as a part of its construction. Complete source for both versions is included.