In computer programming, the term SOLID is a mnemonic acronym for five design principles intended to make software designs more understandable, flexible and maintainable (thanks Wikipedia) – but what does that actually mean?

Here’s the breakdown:
(S)ingle Responsibility Principle
(O)pen/Closed Principle
(L)iskov Substitution Principle
(I)nterface Segregation Principle
(D)ependency Inversion Principle

Dependency Inversion? Inverted from what???

When someone says “inverted”, I instantly try to map my brain to the original – so that I have an accurate description of what (and why) I am inverting. From my research up to this point, I haven’t really seen an accurate description of the “original” we are inverting – except for this example from MartinFowler.com. DIP is the topic, but Structured Analysis is mentioned and explained:

In structured analysis and design, we start with a high-level problem and break it up into smaller parts. 

WE’RE GOING TO MAKE A VEHICLE!

With this top-down approach, high level design is described using the language of the broken up components. We need to know waaaaaay too many details waaaaay too early. The details are made concrete, and if the details need to change for any reason, our design is incredibly volatile.

The Dependency Inversion Principle turns this on it’s head. We move our descriptions up, the other way.

We need a vehicle to shuttle our employees from Point A to Point B, but does it matter what type of engine it’s going to have? Does it HAVE to be a Chevy? Does it have to be green? Does it have to be a car at all? What if the distance is so short, a hoverboard will do? If we save decisions like these until we absolutely have to make them, we may save money and headaches implementing something we don’t even need.

$1000 (hoverboard equivalent of 5 seats at $200/per) or $25,000….not a tough choice. Realizing when you’re about to overplan/overspend however, is tough.

The Dependency Inversion Principle tells us that the most flexible systems are those in which source code dependencies refer only to abstractions, not to concretions.

Continuing with the car metaphor: a car has wheels, a steering wheel, doors, etc…but this is just a blueprint. A blueprint won’t get into an accident on I-85. It’s less volatile than a concrete implementation. A concrete implementation can be driven at 50 mph while on a cell phone. If I rely on the concrete, what I rely on may now be without a bumper.

TL;DR? —> Every change to an abstract interface corresponds to a change to its concrete implementations. Conversely, changes to concrete implementations do not always, or even usually, require changes to the interfaces that they implement. Therefore interfaces are less volatile than implementations. – Clean Architecture: A Craftsman’s Guide to Software Structure and Design, 1/e

 

Share This