SOLID — Liskov Substitution

This is the third article in the SOLID series. If you haven’t read the previous ones about the principles of Single Responsibility and Open-Closed, I strongly recommend that you go back and read them. After all, understanding SOLID works as a succession of facts, making it much easier to understand in the correct order! About the L, it basically consists of the Liskov Substitution Principle and was proposed by Barbara Liskov in 1988. Notice that although it seems that everything in technology is extremely recent, the foundations are actually quite old and extremely solid! Never dismiss something because it is more than 20 years old; all of humanity relies on millennia-old knowledge, and something that is 30 or 40 years old is still a baby! But without further ado, let’s get to the facts!

The principle

Liskov’s description of the principle is:

“What we want 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 not modified when o1 is substituted for o2, then S is a subtype of T.”
Very cool, but probably when reading this for the first time, what comes to mind is, “I didn’t understand anything, it sounds like my math teacher talking.” Despite the somewhat dense formal description, I’ll explain it to you in a simple way! Basically, what Barbara proposed is: child elements, even though they have different types, must have subtypes derived from the same element, and this is where the famous INHERITANCE we see so much in object-oriented programming comes in.
The image below details how it works in practice. Let’s suppose a video stream has a payment process to subscribe to its services. There are two possibilities: corporate subscription or personal use. Therefore, we have the personal and enterprise modes that inherit from the Subscription interface. Thus, Personal can be o1 and Enterprise o2. If we want to substitute one for the other or even create new options, they will automatically be fully compatible, and the rest of the application, such as Billing, does not need to know this logic. The lower layer knows the higher layer, but the reverse does not happen.

In summary, the idea is that we should not have if statements for every specific case and that we can substitute one thing for another transparently or even add new ones without touching the higher-level code. A simple contamination with something that requires placing several if statements in the code can take over the entire system and turn it into a large monolith of nested things. By respecting Liskov, it is entirely possible to maintain compatibility when substituting elements that follow the same pattern and inheritance rules.

Agree? Disagree? Did you like it? Leave your contribution by liking or commenting :).