Liskov Substitution Principle (LSP) in Java

Back to: Java Design Patterns

Liskov Substitution Principle (LSP) in Java

In this article, I am going to discuss Liskov Substitution Principle (LSP) in Java with Examples. Please read our previous article where we discussed the Open-Closed Principle (OCP) in Java. The Letter L in SOLID stands for Liskov Substitution Principle which is also known as LSP. As part of this article, we are going to discuss the following pointers.

Liskov Substitution Principle (LSP) in Java

The Liskov Substitution Principle (LSP) is another key principle in the SOLID acronym. It states that objects of a superclass should be replaceable with objects of its subclasses without breaking the system’s integrity. In simpler terms, any instance of a base class should be able to be replaced by any of its derived classes without affecting the correctness of the program.

This principle ensures that inheritance hierarchies are well-designed and that the behavior of the base class is preserved in its derived classes. When we create a subclass, we should ensure that it behaves in a way that is consistent with the expectations set by the base class. This means that the subclass should not violate any of the contracts or assumptions made by the base class.

For example, consider a class Rectangle with methods for setting and getting its width and height. If we create a subclass Square that inherits from Rectangle, we need to ensure that it behaves in a way that is consistent with the expectations set by the Rectangle class. This means that if we set the width of a Square object, its height should also change to maintain the square shape.

By adhering to the Liskov Substitution Principle, we can create inheritance hierarchies that are easy to understand and maintain. Subclasses will behave in a predictable way, and we can use them interchangeably with their base classes without introducing bugs or unexpected behavior.

The Liskov Substitution Principle (LSP) is a fundamental principle in object-oriented programming and software design. It states that objects of a superclass should be replaceable with objects of its subclasses without affecting the correctness of the program. The LSP offers several advantages, but it also has potential disadvantages.

Example to Understand Liskov Substitution Principle (LSP) in Java

In this example, we have a Rectangle class with setWidth() and setHeight() methods to set the dimensions of the rectangle. There is also a getArea() method to calculate the area of the rectangle. The Square class extends the Rectangle class and overrides the setWidth() and setHeight() methods to enforce the square’s invariant, where the width and height are always the same.

public class Rectangle {
    protected int width;
    protected int height;

    public void setWidth(int width) {
        this.width = width;
    }

    public void setHeight(int height) {
        this.height = height;
    }

    public int getArea() {
        return width * height;
    }
}

public class Square extends Rectangle {
    @Override
    public void setWidth(int width) {
        this.width = width;
        this.height = width;
    }

    @Override
    public void setHeight(int height) {
        this.height = height;
        this.width = height;
    }
}

This violates the Liskov Substitution Principle because the Square class does not behave as a proper substitute for the Rectangle class. The Square class modifies the behavior of the base class methods, which leads to unexpected and inconsistent behavior.

Disadvantages of not using the Liskov Substitution Principle:

• Violation of Client Expectations: Code that relies on the behavior of the Rectangle class may break when interacting with an instance of the Square class. The substitutability is compromised, leading to unexpected results and potential bugs.
• Inconsistent Behaviour: By modifying the base class methods in the Square class, we introduce inconsistent behavior. The Square class violates the behavior expected from a Rectangle (where width and height can be set independently) and creates confusion.
• Reduced Code Reusability: The violation of LSP restricts the reusability of the Rectangle class. Code that expects a Rectangle object may not work correctly when provided with a Square object, limiting code reuse and flexibility.

To adhere to the Liskov Substitution Principle, we need to ensure that any derived class can be used as a substitute for its base class without altering the expected behavior. In this example, we could reconsider the inheritance relationship between Rectangle and Square or apply a different approach to achieve the desired functionality while preserving substitutability and consistency. This can be done as follows:

public abstract class Shape {
    public abstract int getArea();
}

public class Rectangle extends Shape {
    protected int width;
    protected int height;

    public Rectangle(int width, int height) {
        this.width = width;
        this.height = height;
    }

    @Override
    public int getArea() {
        return width * height;
    }
}

public class Square extends Shape {
    private int side;

    public Square(int side) {
        this.side = side;
    }

    @Override
    public int getArea() {
        return side * side;
    }
}

In this refactored example, we have an abstract base class Shape with an abstract method getArea(). Each shape class, such as Rectangle and Square, extends the Shape class and provides its own implementation of the getArea() method.

By adhering to the Liskov Substitution Principle, we ensure that the behavior of the base class (Shape) and its derived classes (Rectangle and Square) remains consistent. Code that interacts with a Shape object can rely on the getArea() method to return the correct area for any shape without any unexpected behavior.

In the case of the Square class, we no longer override the setWidth() and setHeight() methods of the Rectangle class. Instead, we calculate the area based on the side length. This preserves substitutability, as the Square class can be used interchangeably with the Rectangle class wherever a Shape object is expected, without violating the expected behavior.

This design promotes a consistent and reliable usage of the class hierarchy, ensuring that derived classes can be substituted for their base classes without introducing unexpected behavior or breaking client code.

Overall, the Liskov Substitution Principle is an important guideline for designing well-behaved inheritance hierarchies. By ensuring that subclasses behave in a way that is consistent with their base classes, we can create software that is easy to understand and maintain.

Advantages of the Liskov Substitution Principle (LSP) in Java:

The followings are the advantages of using the Liskov Substitution Principle in Java

• Code Reusability: By adhering to the LSP, subclasses can be seamlessly substituted for their base classes. This promotes code reuse and modularity, as the same methods and behaviors can be applied to different objects without modifying the existing code. This reduces duplication, improves maintainability, and enhances overall software productivity.
• Flexibility and Extensibility: The LSP encourages the use of polymorphism, which allows for flexible and extensible code. New subclasses can be added to the system without modifying existing code, enabling the system to adapt to changing requirements or new features. This promotes scalability and future-proofing of the software.
• Enhances Modularity and Abstraction: The LSP enforces the concept of abstraction and promotes a modular design approach. By designing classes that adhere to LSP, developers can reason about behavior and properties at a higher level, without being concerned about specific subclass implementations. This improves code organization, simplifies maintenance, and enhances the overall understanding of the system’s structure.
• Facilitates Testing and Debugging: The LSP improves the testability and debugging process. Subclasses can be easily substituted during testing with mock objects or stubs, allowing for isolated testing of individual components. This facilitates effective unit testing, reduces the scope of potential defects, and simplifies the identification and resolution of issues.

Disadvantages of the Liskov Substitution Principle (LSP) in Java:

The followings are the disadvantages of using the Liskov Substitution Principle in Java

• Violation of Semantics: Incorrect implementation of the LSP can violate the semantics of the base class, leading to unexpected behavior or errors. Subclasses that do not conform to the contract or behavioral expectations of the base class can introduce inconsistencies and compromise the integrity of the system.
• Design Constraints: Adhering strictly to the LSP can impose design constraints and limitations. Subclasses must satisfy all the requirements and invariants of the base class, which can restrict the flexibility of individual subclasses. This can lead to complex hierarchies or result in compromises in design decisions.
• Increased Complexity: Working with a large number of subclasses and ensuring their proper adherence to the LSP can increase the complexity of the codebase. It requires careful consideration of the inheritance hierarchy and maintaining a clear understanding of the relationships and contracts between classes. This complexity can make the code more difficult to understand and maintain, particularly in large-scale systems.
• Performance Overhead: In some cases, adhering strictly to the LSP may introduce performance overhead. Subclasses that have to comply with all the requirements of the base class may need to perform additional checks or computations, impacting runtime performance. Balancing adherence to the LSP with performance considerations is necessary to achieve optimal results.

In the next article, I am going to discuss Interface Segregation Principle (ISP) in Java with Examples. Here, in this article, I try to explain Liskov Substitution Principle (LSP) in Java with Examples. I hope you enjoy this Liskov Substitution Principle (LSP) in Java article.