SOLID - Liskov Substitution Principle in C#

The SOLID principles are foundational concepts in object-oriented design that guide developers in creating manageable, maintainable, and scalable systems. Among these principles, the Liskov Substitution Principle (LSP) stands out for its focus on ensuring that subclasses can be used in place of their base classes without affecting the correctness of the program. This principle, named after Barbara Liskov, can be succinctly summarized as: objects of a superclass shall be replaceable with objects of its subclasses without altering the desirable properties of the program.

The Principle Explained Through Food

Imagine you’re working on a food ordering system, and you have a base class called FoodItem that defines a method Prepare. This method outlines the steps required to prepare a dish.

public abstract class FoodItem
{
    public abstract void Prepare();
}

You then have several subclasses representing specific food items, such as Pizza and Salad.

public class Pizza : FoodItem
{
    public override void Prepare()
    {
        Console.WriteLine("Bake the pizza.");
    }
}

public class Salad : FoodItem
{
    public override void Prepare()
    {
        Console.WriteLine("Toss the salad.");
    }
}

According to LSP, you should be able to substitute any subclass of FoodItem (like Pizza or Salad) for a FoodItem object without causing any issues in your system. This means that anywhere in your code where you use a FoodItem, you can use a Pizza or a Salad instead, and the behavior of your program remains correct and predictable.

Violating LSP with Food

Now, let’s introduce a violation of the Liskov Substitution Principle by adding a new subclass, PrepackagedFood, which has a different preparation process.

public class PrepackagedFood : FoodItem
{
    public override void Prepare()
    {
        throw new NotImplementedException("Prepackaged food does not require preparation.");
    }
}

In this scenario, substituting PrepackagedFood for FoodItem could lead to runtime errors or unexpected behavior, specifically when the Prepare method is called. This is because PrepackagedFood fundamentally changes the expectations of how the Prepare method works, thus violating LSP. The system expects that calling Prepare on any FoodItem will result in some preparation steps being executed, but with PrepackagedFood, this expectation is broken.

Correcting the Violation

To adhere to LSP, we need to ensure that all subclasses of FoodItem can indeed be used in place of FoodItem without altering the behavior of the system. One approach is to refactor our classes to more accurately represent the relationships and behaviors involved.

For instance, we could introduce a new method or property to handle the preparation check differently or redesign our class hierarchy to separate items that do not require preparation from those that do.

public abstract class FoodItem
{
    public virtual bool RequiresPreparation => true;
    public abstract void Prepare();
}

public class PrepackagedFood : FoodItem
{
    public override bool RequiresPreparation => false;
    
    public override void Prepare()
    {
        if (!RequiresPreparation)
        {
            Console.WriteLine("No preparation needed.");
            return;
        }
    }
}

By introducing a property RequiresPreparation, we can now differentiate between food items that need preparation and those that do not, while still adhering to the Liskov Substitution Principle. This ensures that our system’s behavior remains predictable and correct, even as we substitute different subclasses of FoodItem.

Wrapping Up

Understanding and applying the Liskov Substitution Principle is crucial for designing robust, flexible systems in object-oriented programming. By ensuring that subclasses can be used interchangeably with their base classes without affecting the program’s correctness, developers can create more modular and maintainable code. Through the analogy of food and preparation, we’ve seen how violating LSP can lead to issues and how we can refactor our code to comply with this principle, ensuring our software design remains solid and reliable.