WTF is the Liskov’s Substitution Principle?

Source Google Images.

So hi again, this time I will try to explain what is Liskov’s Substitution Principle (a.k.a. Behavioral Subtyping), I will do this using C#, which is an OOP(Object Oriented Programming Language), so for those who are familiar with Python should read it too.

First of all you should know that LS Principle states that an object from the base class (or parent class) shoud be replaced by an object of the derived class (or child) without throwing any erros or changing the behavior of the base class.

Here is a simple example to illustrate this, let’s say we have a class Rectangle, which will take in width and height (please see below)

Rectangle class definiton

And we have a Square class that will inherit from the Rectangle

Square class definition

Usually inheritance is used in order to avoid repeating yourself by writting the same code again and again, so to achive this we will add the area method in the base class so that all its derived classes can use it as well

This method is included inside the Rectangle class

Now if we run this code with giving some values we will get something like this:

Results printed in console

As you can see every thing seems fine, values are returned as expected, there is nothing to worry about, but what if we try one more time giving other values to the square object

WTF??

As far as we know all squares are rectangles, but a rectangle is never a square, since square’s sides must have the same length, so for the logic we are using here by deriving the Square class from the Rectangle class seems just fine; but see what is happening above? Well if you noticed, two different values where given to the square object and the area method worked as expected, however it is not a square, since the length of the width and height are different.

For this reason this hierarchy design is not suitable, since it is violating the LS Principle; to fix this we could say that we can add an exception in case two different values are passed to a square object, or we could override the area method by defining a new one under the Square class, however the first “solution” will violate the principle two because it will be throwing an error and that is not permited, and the second one will make us write more code duplicating it so that is a no-go either.

So you must be thinking, ok so what should I do then? Well in this case the best solution would be to create a Shape class from which both Square and Rectangle classes will inherit, and let Square and Rectangle define their own area methods.

This way if we test again, the results will be right, and the best part is that you can replace the Shape class(base class) with both Rectangle or Square and there will be no errors.

Keep in mind this principle, and you’ll write better code (with less flaws)!