Liskov’s Substitution Principle
In languages like C# The clue to obtain abstraction and polymorphism is by inheritance and it’s in this characteristic that the Liskov Substitution Principle is based on.
Which are the basics of design that the inheritance has to follow in a particular case? Or what is the best way of creating inheritance hierarchies between classes? These are some questions answered by this principle.
This might be hard to understand but I will try to explain it the best way possible. All of the above in simpler words is:
“Ability to replace any instance of a parent class with an instance of one of its child classes without negative side effects”
This means that in a block of code an instance created by a child class can replace a parent instance and the result should be the same as when using the parent class.
In the following example we are going to use the instance apple created with the parent class Apple which will return red thus printing “I’m an apple object of red color”
But now if we use the subclass Orange to create an apple instance, we will get the following output,
which is totally incorrect as apples aren’t supposed to be orange colored.
So how could we fix this? For this example, we could create a Fruit Parent class, and both apples and oranges will inherit from it. Apple will inherit directly from Fruit and Orange will inherit from Fruit by inheriting from Apple.
This way both subclasses will have their own methods if needed and can replace the parent class without any changes in the result
Rectangles and Squares
Mathematically speaking a square is the same as a rectangle: they both have 4 sides so why not make a square inherit from a rectangle?
If we were to create a class Rectangle, we would include width and height, as both values would be different:
The Square class would inherit from the Rectangle class, but as a square has all its sides the same length it would only need one value:
“Running this code will result in the first shape having an area of 140 and the second an area of 100. You’d then be tempted to fire up the debugger to figure out what’s going on. The behavior of the subclass has changed.”
“Using Uncle Bob’s words, the code violates LSP since subtype is not substitutable for its base type”
So how could we solve this problem? One solution would be to use the example of the Apple and the Orange. The same principle can be applied here, just as we created a Class Fruit, we can also create a parent class for both Rectangle and Square classes to inherit from, a Shape class for example, that has no properties that way each child class would have its own specific properties.
Conclusions:
LSP is not to be taken lightly. Hierarchies are important in Object Oriented Programming and are the foundations of our design, if there is a failure in it, it could be hard to fix the disaster afterwards. Knowing about this it is a good practice to have these laws in mind to have a cleaner error free product.
Resources:
https://dotnettutorials.net/lesson/liskov-substitution-principle/
