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

There you have it, follow these principles and you’ve begun your path to clean design.
In this series, we’re going to try to really understand each one of the principles.

LSP – Liskov Substitution Principle

   

If it looks like a duck, and quacks like a duck, it may not actually be a duck…

I found the following quote in Clean Architecture: A Craftsman’s Guide to Software Structure and Design. It is a snippet from Data Abstraction and Hierarchy, written by Barbara Liskov:  What is wanted here is something like the following substitution property: If for each object o1 of type S there is an object o2 of type T such that for all programs P defined in terms of T, the behavior of P is unchanged when o1 is substituted for o2 then S is a subtype of T.”

We inherit so we don’t write the same things over and over again. We inherit to form a logic, because we think in categories. But this can be very dangerous. The square/rectangle example has been used many times as an example of this.

We look at a couple of factors, determine they match, and pat ourselves on the back for using inheritance. The problem arises when manipulation starts. If I have to splatter my code with “If” checks because I can’t quite use all of the inherited properties as is, I have violated the Liskov Substitution principle.

This is a problem because, without clean inheritance, we open ourselves to constant band-aids and maintenence headaches.

LSP violations don’t just stop at inheriting issues. In Clean Architecture, Uncle Bob uses a real world example of this in the form of URIs. The example is for a taxi service dispatch app that coordinates all of the nearby taxi services. They’ve all been pretty good about formatting their URI to receive the pertinent information from the dispatch app in the right order….except *dramatic music* a rebel faction called Acme.com. The dispatch developer literally has to code in such a way that a check needs to be made for acme.com :

Image
Image

 

Now we have to keep up with the taxi company name in case it changes or the company gets sold, all because Acme.com programmed their uri to abbreviate destination. Whereas it would have been nice to just drop acme.com in the start of the uri and execute the same format as every other taxi company.

Apparently Acme.com holds alot of weight and doesn’t handle change requests nicely.

Next time, we’ll explore the Interface Segregation Principle – until then, happy clean coding!

*Comic created using Pixton

 

Share This