Liskov Substitution Principle (LSP)

 In this article, we are going to discuss what is Liskov Substitution Principle (LSP) with real-world examples.

So your Object-Oriented Programming skills are at par and now you want to apply your knowledge to live projects.

After all, understanding the 4 basic pillars of Object-Oriented Programming and knowing a few cool things like constructor chaining and static methods should be enough to pull off the job right? Well, sorry to disappoint you but a S.O.L.I.D wall awaits!

Knowing the basics is one thing but writing good quality code is another. This is where the 5 most important software design principles come into play! Out of those, the most important and the most misunderstood principle is the Liskov Substitution Principle (LSP). 

Well, guess what? The gods of Google have landed you on the right article because in this article we are going to talk all about LSP. So hop on as this will be the only article you’ll ever need for understanding the infamous LSP!

Liskov Substitution Principle (LSP)

Simply put, the Liskov Substitution Principle (LSP) states that objects of a superclass should be replaceable with objects of its subclasses without breaking the application. 

In other words, what we want is to have the objects of our subclasses behaving the same way as the objects of our superclass.

So the next time you create an object of the subclass by mistake, you should still be fine (given you implemented LSP).

But Mohit, what does this even mean? How can an object of another class behave the same way as another’s? You might ask. Let me give you a real-life example and it will be crystal clear to you.

Remember in 5th grade when your maths teacher taught you the formula of squares for rectangles and squares? I always remembered square as the more “formula-friendly” rectangle. It is after all a rectangle with equal sides, isn’t it? 

Now suppose you have a base class Rectangle and I tell you to create a new class Square and maximize reuse. Will you inherit the Rectangle class inside the Square class?

No matter how tempting it might sound or how well you intend to handle it, this small “reuse” will be totally WRONG!

Let us go by an example:

By looking at the above scenario you might still argue that it looks pretty consistent. That is true for the language you are coding in and also for Mathematics but a Square might not always satisfy the behavior of a Rectangle.

This is what I mean:

Your ClientMethod() expects a Rectangle and asserts a value of the area. All was well up to this point but now when we do rec.setHeight(4), our Square will set both its sides as 4, and that will totally mess up the assert statement.

We were expecting a Rectangle of sides 5 and 4 to have an area of 20 but we got a Square with sides 4 and 4 and area 16.

Hence, using Square’s object in place of the Rectangle’s object totally breaks LSP! Read the definition of LSP again:

“Simply put, the Liskov Substitution Principle (LSP) states that objects of a superclass should be replaceable with objects of its subclasses without breaking the application.”

This was just a small example. There will be numerous other problems if you plan on creating an algebra application inheriting a Square from a Rectangle. 

Real-life Examples Which Break Liskov Substitution Principle (LSP)

1. Your landlord wanted you to fix the main gate’s light bulb but you gave him Diwali vibes instead! (He won’t be happy!)

2. You fed your neighbor’s pet duck expired Bread and now it’s dead. You decided to replace it with a toy duck. (He won’t be happy!)

Conclusion

The Liskov Substitution Principle is one of the five SOLID principles of object-oriented programming. All the five principles combined are helpful in making object-oriented code more readable, maintainable, and easier to upgrade and modify.

Thank you! Happy Learning.