Liskov Substitution Principal in C# with Example and Video Tutorial

The Liskov Substitution Principle (LSP) is one of the five SOLID principles of object-oriented programming. It was introduced by Barbara Liskov in 1987 and emphasizes the importance of substitutability among objects of a base class and its derived classes. In simpler terms, if a class is a subclass of another class, it should be able to replace its parent class without affecting the correctness of the program. Let's delve into the principles of Liskov Substitution with practical C# code examples.

Liskov Substitution Principle Basics

The principle is often stated as follows:

"Subtypes must be substitutable for their base types without altering the correctness of the program."

To put it more practically, if a class B is a subclass of class A, an object of class A should be replaceable with an object of class B without affecting the program's behavior.

Code Example: Shapes Hierarchy

Let's consider a simple example with a hierarchy of geometric shapes. We have a base class Shape and two derived classes Rectangle and Square.

public class Shape
{
    public virtual double Area()
    {
        return 0;
    }
}

public class Rectangle : Shape
{
    public double Width { get; set; }
    public double Height { get; set; }

    public override double Area()
    {
        return Width * Height;
    }
}

public class Square : Shape
{
    public double SideLength { get; set; }

    public override double Area()
    {
        return SideLength * SideLength;
    }
}

Now, let's create a method that calculates the total area of a list of shapes:

public class AreaCalculator
{
    public double CalculateTotalArea(List<Shape> shapes)
    {
        double totalArea = 0;

        foreach (var shape in shapes)
        {
            totalArea += shape.Area();
        }

        return totalArea;
    }
}

This seems fine so far, but what if we decide to extend our hierarchy and add a new shape, say, a Circle class?

public class Circle : Shape
{
    public double Radius { get; set; }

    public override double Area()
    {
        return Math.PI * Radius * Radius;
    }
}

Now, let's use the AreaCalculator with a list containing a mixture of rectangles, squares, and circles:

List<Shape> shapes = new List<Shape>
{
    new Rectangle { Width = 5, Height = 10 },
    new Square { SideLength = 4 },
    new Circle { Radius = 3 }
};

AreaCalculator calculator = new AreaCalculator();
double totalArea = calculator.CalculateTotalArea(shapes);
Console.WriteLine($"Total Area: {totalArea}");

This is where Liskov Substitution Principle becomes crucial. The CalculateTotalArea method should work with any shape without modification. The fact that we can add a new shape (Circle) without altering the existing code demonstrates adherence to the Liskov Substitution Principle.

Violating Liskov Substitution Principle

Now, let's explore what happens when we violate Liskov Substitution. Suppose we decide to create a special type of square called ColoredSquare:

public class ColoredSquare : Square
{
    public string Color { get; set; }
}

If we now try to use ColoredSquare in our previous example:

List<Shape> shapes = new List<Shape>
{
    new Rectangle { Width = 5, Height = 10 },
    new Square { SideLength = 4 },
    new ColoredSquare { SideLength = 3, Color = "Red" }
};

AreaCalculator calculator = new AreaCalculator();
double totalArea = calculator.CalculateTotalArea(shapes);
Console.WriteLine($"Total Area: {totalArea}");

This will compile and run without errors, but it violates Liskov Substitution Principle. The ColoredSquare is not substitutable for its base type Square in the context of the CalculateTotalArea method. It has introduced additional properties (Color) that are not present in the base class, potentially causing unintended consequences.

Conclusion

Liskov Substitution Principle is a fundamental concept in object-oriented design. Adhering to this principle ensures that the substitution of derived classes for their base classes does not introduce unexpected behaviors. By following LSP, you create a more maintainable and flexible codebase. Always consider whether your derived classes can truly substitute their base classes in all contexts to maintain a strong and reliable object-oriented design.