Liskov Substitution Principle: Complete Guide with Examples

The Liskov Substitution Principle (LSP) is a fundamental concept in object-oriented design that states objects of a superclass should be replaceable with objects of its subclasses without breaking the application or altering the program’s correctness. This principle, introduced by Barbara Liskov in 1987, focuses on behavioral substitutability rather than just syntactic compatibility, ensuring that subclasses maintain the same expected behavior as their parent classes.

Contents

• Understanding LSP Fundamentals
• Key Characteristics of LSP
• Practical Examples of LSP Implementation
• Common LSP Violations and Their Consequences
• How to Ensure LSP Compliance
• Benefits of Following LSP

Understanding LSP Fundamentals

The Liskov Substitution Principle is one of the five SOLID design principles and represents the “L” in the acronym. At its core, LSP addresses the fundamental question: What makes a subtype a proper subtype?

According to the DigitalOcean technical explanation, LSP states that:

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

This principle goes beyond simple inheritance and focuses on the behavioral contract between classes. As Baeldung explains, LSP helps structure object-oriented design by ensuring that subclasses can safely substitute their parent classes without introducing unexpected behavior.

The principle is based on the concept of “substitutability” – a principle in object-oriented programming stating that an object may be replaced by a sub-object without breaking the program, as noted in the Wikipedia definition.

Key Characteristics of LSP

Behavioral Subtyping

LSP is a type of behavioral subtyping defined by semantic, rather than syntactic, design consideration. This means it’s not enough for a subclass to simply compile with the parent class - it must also behave in ways that are consistent with the parent’s expectations.

Contract Preservation

The principle requires that all subclasses preserve the contracts established by their parent classes. This includes:

• Maintaining the same method signatures
• Adhering to the same preconditions and postconditions
• Preserving invariants established by the parent class

No Client Awareness

As Tom Dalling’s blog explains:

Functions that use pointers to base classes must be able to use objects of derived classes without knowing it.

This means client code should never need to know whether it’s working with a parent class or a subclass instance.

Practical Examples of LSP Implementation

Example 1: Proper Vehicle Hierarchy

// Interface that defines the contract
interface Vehicle {
    void startEngine();
    void accelerate();
    void brake();
    double getMaxSpeed();
}

// Proper implementation of Car class
class Car implements Vehicle {
    private boolean engineRunning = false;
    private double currentSpeed = 0;
    
    @Override
    public void startEngine() {
        engineRunning = true;
    }
    
    @Override
    public void accelerate() {
        if (engineRunning) {
            currentSpeed = Math.min(currentSpeed + 10, getMaxSpeed());
        }
    }
    
    @Override
    public void brake() {
        currentSpeed = Math.max(currentSpeed - 15, 0);
    }
    
    @Override
    public double getMaxSpeed() {
        return 120.0; // km/h
    }
}

// Proper implementation of Motorcycle class
class Motorcycle implements Vehicle {
    private boolean engineRunning = false;
    private double currentSpeed = 0;
    
    @Override
    public void startEngine() {
        engineRunning = true;
    }
    
    @Override
    public void accelerate() {
        if (engineRunning) {
            currentSpeed = Math.min(currentSpeed + 15, getMaxSpeed());
        }
    }
    
    @Override
    public void brake() {
        currentSpeed = Math.max(currentSpeed - 20, 0);
    }
    
    @Override
    public double getMaxSpeed() {
        return 180.0; // km/h
    }
}

In this example, both Car and Motorcycle properly implement the Vehicle interface. Client code can work with either implementation without modification:

public class TrafficController {
    public void manageTraffic(Vehicle vehicle) {
        vehicle.startEngine();
        vehicle.accelerate();
        // ... more operations
    }
}

// Usage
TrafficController controller = new TrafficController();
controller.manageTraffic(new Car());      // Works fine
controller.manageTraffic(new Motorcycle()); // Works fine

Example 2: Shape Hierarchy with Area Calculation

// Abstract base class
abstract class Shape {
    public abstract double calculateArea();
}

// Proper implementation of Rectangle
class Rectangle extends Shape {
    private double width;
    private double height;
    
    public Rectangle(double width, double height) {
        this.width = width;
        this.height = height;
    }
    
    @Override
    public double calculateArea() {
        return width * height;
    }
}

// Proper implementation of Circle
class Circle extends Shape {
    private double radius;
    
    public Circle(double radius) {
        this.radius = radius;
    }
    
    @Override
    public double calculateArea() {
        return Math.PI * radius * radius;
    }
}

This hierarchy properly implements LSP because both subclasses maintain the same behavioral contract as the parent class - they both calculate area according to their specific geometric properties.

Common LSP Violations and Their Consequences

Violation 1: Rectangle-Square Problem

This is the classic example that demonstrates LSP violation:

class Rectangle {
    protected double width;
    protected double height;
    
    public Rectangle(double width, double height) {
        this.width = width;
        this.height = height;
    }
    
    public void setWidth(double width) {
        this.width = width;
    }
    
    public void setHeight(double height) {
        this.height = height;
    }
    
    public double getArea() {
        return width * height;
    }
}

// Violation: Square extends Rectangle but breaks the contract
class Square extends Rectangle {
    public Square(double side) {
        super(side, side);
    }
    
    // Violation: Overrides setWidth to also change height
    @Override
    public void setWidth(double width) {
        this.width = width;
        this.height = width; // This breaks Rectangle's behavior
    }
    
    // Violation: Overrides setHeight to also change width
    @Override
    public void setHeight(double height) {
        this.height = height;
        this.width = height; // This breaks Rectangle's behavior
    }
}

The problem is that Square changes the behavior of Rectangle’s setters. Client code expecting Rectangle behavior will fail:

public void resizeRectangle(Rectangle rect, double newWidth, double newHeight) {
    rect.setWidth(newWidth);
    rect.setHeight(newHeight);
    System.out.println("Area: " + rect.getArea());
}

// This works as expected
resizeRectangle(new Rectangle(5, 10), 8, 12); // Area: 96

// This fails expectations
resizeRectangle(new Square(5), 8, 12); // Area: 64 (expected: 96)

Violation 2: Null Return Violation

As mentioned in the DEV Community article, a violation occurs when:

A derived method returns a null value for a list when there is a convention not to return null for empty collections but instead to return initialized collections with zero items count.

interface DataProvider {
    List<String> getData();
}

class GoodDataProvider implements DataProvider {
    @Override
    public List<String> getData() {
        return new ArrayList<>(); // Returns empty list, not null
    }
}

class BadDataProvider implements DataProvider {
    @Override
    public List<String> getData() {
        return null; // Violates LSP - breaks client expectations
    }
}

Violation 3: Type-Switching Behavior

Another common violation is when client code needs to use instanceof or downcasting, as noted in the Baeldung article:

// Violation: Client code needs to know concrete types
class PaymentProcessor {
    public void processPayment(Payment payment) {
        if (payment instanceof CreditCardPayment) {
            // Special handling for credit cards
        } else if (payment instanceof PayPalPayment) {
            // Special handling for PayPal
        }
        // This violates LSP because client needs to know types
    }
}

Violation 4: Strengthening Preconditions or Weakening Postconditions

According to the GitHub Pages explanation, LSP is violated when:

S is a derivate of T when passed to f in the guise of objects of type T, objects of type S cause f to misbehave.

This happens when:

• Subclasses strengthen preconditions (require more than parent)
• Subclasses weaken postconditions (provide less than parent)
• Subclasses change invariants established by parent

How to Ensure LSP Compliance

1. Use Composition Over Inheritance

When tempted to use inheritance, consider whether composition would be a better fit. As the Alpharithms article suggests, focus on behavioral contracts rather than inheritance hierarchies.

2. Design for Behavioral Contracts

Before creating subclasses, clearly define the behavioral contract that must be maintained:

// Good contract definition
interface Payment {
    boolean process(double amount);
    boolean canProcess(double amount); // Clear precondition
    ProcessingResult getResult();      // Clear postcondition
}

3. Follow the “Is-A” Test

Ask yourself: “Is a subclass truly an instance of the parent class in all meaningful ways?” If not, consider interface implementation instead of inheritance.

4. Use Dependency Injection

Rather than creating tight inheritance hierarchies, use dependency injection to allow substitution:

class OrderProcessor {
    private final PaymentStrategy paymentStrategy;
    
    public OrderProcessor(PaymentStrategy paymentStrategy) {
        this.paymentStrategy = paymentStrategy;
    }
    
    public void processOrder(Order order) {
        // Can use any PaymentStrategy implementation
        paymentStrategy.process(order);
    }
}

Benefits of Following LSP

1. Improved Code Reusability

When classes properly implement LSP, you can reuse code that works with the parent class across all subclasses.

2. Better Testability

You only need to test the base class behavior once, and all compliant subclasses will automatically work correctly.

3. Reduced Coupling

Client code becomes less coupled to specific implementations, as it only needs to interact with the parent interface.

4. Enhanced Maintainability

Adding new subclasses doesn’t require modifying existing client code, following the Open/Closed Principle.

5. Clearer Design Intent

Following LSP forces you to think clearly about behavioral contracts and class relationships.

As the NashTech Blog emphasizes:

Simply put, the Liskov Substitution Principle (LSP) states that objects of a superclass should be replaceable with objects of its subclasses without breaking the application.

By understanding and implementing LSP correctly, you’ll create more robust, maintainable, and flexible object-oriented designs that stand the test of time.

Sources

1. SOLID Design Principles Explained: The Liskov Substitution Principle - Stackify
2. SOLID Design Principles Explained: Building Better Software Architecture - DigitalOcean
3. What is an example of the Liskov Substitution Principle? - Stack Overflow
4. Liskov substitution principle - Wikipedia
5. Liskov Substitution Principle (LSP): SOLID Design for Flexible Code - αlphαrithms
6. Liskov Substitution Principle in Java - Baeldung
7. What Is The Liskov Substitution Principle (LSP)? - ITU Online IT Training
8. SOLID Class Design: The Liskov Substitution Principle — Tom Dalling
9. Examples on the violation of Liskov Substitution Principle (LSP) - DEV Community
10. Liskov Substitution Principle Explained - Reflectoring

Conclusion

The Liskov Substitution Principle is a cornerstone of good object-oriented design that ensures subclasses can safely replace their parent classes without introducing unexpected behavior. By focusing on behavioral contracts rather than just inheritance hierarchies, LSP helps create more maintainable, flexible, and robust software systems.

Key takeaways include:

• Always test whether your subclasses truly maintain the parent class’s behavioral contract
• Avoid common violations like changing method behavior, returning unexpected null values, or requiring type-checking in client code
• Consider using composition over inheritance when behavioral contracts can’t be maintained
• Design clear interfaces that define expected preconditions, postconditions, and invariants
• Remember that LSP violations often indicate deeper design problems that need to be addressed

Following LSP consistently will lead to code that’s easier to test, maintain, and extend, ultimately resulting in higher quality software architectures.