The DIP deals with avoiding mixing different levels of abstraction in your code. In this article we will explore the last of these principles in depth. [...] I want to show you how depending on abstractions makes our lives easier in a larger example. Since we're going to be loading, updating and storing bikes a lot in our application I would like an Api for that. It would not be such a good idea to write the same queries or perform the same validation over and over.

He includes two examples - one a bit simplistic involving bike storage and another more complex that uses interfaces to define structure and object injection rather than passing data around. He also tries to help clear up some of the confusion that might happen around dependency inversion and dependency injection.

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.

[In a Service Locator] all the dependencies are provided by a builder, which serves as a registry of dependencies and/or service definitions. The service locator knows how to instantiate each dependency. Such service exposes methods like 'getMailer()', 'getLogger()' etc. A service locator centralises the configuration detailing classes and parameters involved on objects instantiations.

He includes some sample code showing the structure of a Select implementation using a "Mailer" identifier and definitions of the classes to load for it. He also includes a bit of documentation of the (simple) API you can use to work with the tool - setting namespaces, replacing class definitions, creating definitions and finding the resource associated with a definition (to name a few).