The best LSP real world example explained for you! - OOP talk - level: beginner/intermediate

In this post I wrote about 2 really important things, the first one was the abstraction, which is almost self-explanatory if you read the post and, the second one is an acronym*SOLID, which stands for 5 techniques that will certainly improve your coding style, skill and level of professionalism. There is no need to use/study them in any order and, to prove that, I'll talk about the third concept today, probably the most confusing one when you don't read carefully, the LSP.

Study the SOLID principles to be prepared, you should. Yes, hmmm. - Yoda

The reason to write about it is that I saw a few days ago an implementation which I can consider the best LSP implementation I've ever seen running on production in the company I'm working (kudos to Eugene Osovetsky and Justin Thompson for the good work) and I want to share with you all. Just to keep you reading I'll explain what LSP is to make more sense afterwards.

So basically, LSP stands for Liskov Substitution Principle, which is clearly a principle of some sort of substitution created by a very smart guy called Liskov, right? Well, almost right, in fact, the first person to talk about it was Barbara Liskov in 1987 and it's more about the concept of abstraction and hierarchy using a more semantic approach (the real use/meaning of a class/program/function) than a syntactic approach (the structure of a class/program/function). Easy right? Okay, let's dissect this a bit.

The difference between the two approaches is the way we'll look at a class and its usage in a program. To make it clearer let's talk about an example:

Imagine you have a fast food company with delivery service and your company holds many business rules to handle all areas inside of it, let's say from sales to delivery. Each area holds an X number of rules using different types of techniques like in person customer approach, phone sales, vehicle management and team schedules to achieve your goal as a company that is to produce fast food and deliver your goods, well this is the semantic way of seeing it, with that we'll end up with a set of class somewhat like this, for example:

Semantic approach:

The Fast Food company have rules and for sales, it uses phone sales.

Syntactic approach:

(SpecificImplementation inherits: RuleType derived from Rule) Company

They are describing the same thing, with different visions, it's clear that using the Semantic approach we can determine what does what and what we can change for what. In this case (mixing with the syntactic) we can exchange the RuleType (Sales) because it is a subtype of Rule, after all, we just need to create a new RuleType, that will make use of a specific implementation (Phone sales).

Yes, it's somehow related to OCP, which will be subject for a future conversation, but for now, we can stay with the dense one sentence version of this concept, well set in this phrase by Barbara Liskov and Jeannette Wing in 1994:

Subtype Requirement : Let f(x) be a property provable about objects x of type T. Then f(y) should be true for objects y of type S where S is a subtype of T.

But wait, why should I use this hard to understand/useless principle? Ok young grasshopper, let's have a counter-example as well pointed out in a comment by Sachin. So, what traps or problems occur when you don't follow this principle?

The short answer for that is that you will end up with a less maintainable and extensible piece of software. Let's do a quick look at those items:

Maintainability are activities known as Software maintenance, which in software engineering is the modification of a software product after delivery to correct faults, to improve performance or other attributes - from ISO/IEC 14764:2006 

Extensibility is a software design principle defined as a system’s ability to have new functionality extended, in which the system’s internal structure and data flow are minimally or not affected, particularly that recompiling or changing the original source code is unnecessary when changing a system’s behavior, either by the creator or other programmers. - Really well defined by Niklas Johansson and Anton Löfgren in the great article Designing for Extensibility.

Those items alone deserve a new post in the future, but let's keep it simple for now in case you have any questions about it please reach out and let's talk, that way all of us can become better developers.

I hope you all like it and it can be the start of a discussion about coding principles, I love to talk about it <3. See you all folks

Cheers,

Emerson Mellado

emersonmellado.com

* I promise to write a new post about some acronyms soon :)