Liskov Substitution Principle and its significance

Table of contents

Reading Time: 3 minutes

Solid Principles:

Solid principles establish practices that grant software development with considerations for maintaining as well as extending as the project grows. Adopting these practices can also contribute to avoiding code smells, refactoring code, and Agile or Adaptive software development.

Liskov Substitution Principle and its significance:

“Objects in a program should be replaceable with instances of their subtypes without altering the correctness of that program”

For example, we have a base Class Rectangle & a derived Class Square.

Rectangle as base class has getter and setter for height & width And method to calculate Area.
public virtual void SetWidth(int width) { _width = width; }

public virtual void SetHeight(int height) { _height = height; }

public float getArea() { return _width * _height; }

virtual methods are overridden in Square Class as

public override void SetWidth(int width) { _width = width; _height = width; }

public override void SetHeight(int height) { _height = height; _width = height;

Lets assume we have a method in Some class
public float CalculateArea(float height,float width) { Rectangle rect=new Rectangle(); rect.SetHeight(height); rect.SetWidth(width); return rect.GetArea(); }
which returns area.

According to Liskov’s principle, if we replace the Rectangle class with the Square class in the CalculateArea method, the functionality should not be affected.

But have close look at what is happening after replacing.

Public float CalculateArea(float height,float width) { Rectangle rect=new Square(); rect.SetHeight(height); rect.SetWidth(width); return rect.GetArea(); }

if u had passed height=2, width=3 in earlier case we would have got 2*3=6 as answer But now we will be getting 3*3=9 as answer.

This means we are breaking Liskov’s principle if we give this example for inheritance.

Is Liskov Substitution Principle a practical concept..?

Totally! Square/square shape is an exemplary model that assists you with understanding the idea. In reality, you’re probably not going to see a square shape/square case! Be that as it may, in one of the activities I dealt with previously, the other programmer made a profound legacy order of assets, where I saw infringement of LSP.

I can’t recollect the model on top of my head. Yet, the standard attempts to assist you with picking your deliberations right. There is a silly method of saying this standard: assuming it seems as though a duck and quacks like a duck however utilizes a battery, you got your deliberations wrong. One is a toy, the other is a creature.

You can’t make a superclass called duck and acquire ToyDuck and AnimalDuck from it. It’s ideal to avoid profound legacy pecking orders and favor synthesis over legacy. At the point when you see profound legacy pecking orders, consistently check whether LSP is substantial. Trust that makes a difference!

Conclusion:

This topic will be used in plenty of useful places in your projects. Liskov Principle is an important concept and easy to master as well. So, I would say, keep practicing. That’s all basic I have in my mind as of now, related to the Liskov Principle, which could be understood by any beginner-level programmer. The language does not matter. You can write in any language you want to write.

So, focus on the logic. If you found anything missing or you do not relate to my view on any point, drop me a comment. I will be happy to discuss. For more blogs, click here