Liskov Substitution Principle (LSP) in Java

The SOLID principles are a set of five design principles that enhances object-oriented programming (OOP). This blog post reviews the Liskov Substitution Principle(LSP) and shows how it can be applied using Java examples.

SOLID Design Principle is made up of five different principles:

• S: Single Responsibility Principle(SRP)
• O: Open-Closed Principle(OCP)
• L: Liskov Substitution Principle(LSP)
• I: Interface Segregation Principle(ISP)
• D: Dependency Inversion Principle DIP)

Liskov Substitution Principle

The Liskov Substitution Principle (LSP) emphasizes that objects from a superclass can be replaced with objects from a subclass without affecting the program's correctness. This principle ensures that derived classes follow the contract established by their base classes, thereby improving code reliability and preventing unexpected behavior in polymorphic scenarios.

This is the third principle of the SOLID design principle group. It tells us:

We can replace subclass or child class objects with base class objects whenever necessary. This substitution should not change the program's desired properties.

Let us demonstrate this with a simple example. Assume we have the class Bird, which has two methods: eat() and fly(). Class Eagle has now inherited the Bird class. The Eagle class now owns the eat() and fly() methods. So we can use the object of the Bird class instead of the object of the Eagle class. This will not disrupt the existing functionalities.

It sounds simple, and it is. But there's a catch here. This principle applies to classes that exhibit the same behavior. We assume that the Bird and Eagle classes behave similarly. At the same time, the subclass's overridden methods should behave the same way as the superclass's methods. Based on this assumption, we can use the Bird object rather than the Eagle object.

But what happens if the parent and child classes do not behave similarly? What happens if the overridden methods of the subclass do not behave like the superclass's methods. How can we apply the Liskov Substitution Principle in those cases?

Let us consider another example. We will explore this principle with a Java-based Payment Processing System.

Example without LSP

Assume an e-commerce platform has different types of payment methods. Customers can pay with Credit cards, Debit cards, PayPal, or Cash.

The payment classes override the processPayment(...) method. This method will contain logic for processing payments. We may need to consume third-party APIs to settle Credit card or PayPal payments.

But in the case of cash payments, there is no need to process. We can simply accept the cash. As a result, the behavior of precessPayment(...) differs when cash payments are made.

The behavior of the processPayment(...) method is not the same in all the subclasses. So this violates the Liskov Substitution Principle.

Example with LSP

To implement the Liskov Substitution Principle, we created two interfaces: IPayment and IOnlinePayment.

IPayment is the interface for all payment types. IOnlinePayment is the interface for all kinds of online payments.

CreditCardPayment and PayPalPayment have implemented the IOnlinePayment interface.

We've overridden the authenticate() and processPayment() methods in the classes.

Here is our class on cash payments. This class only implements the IPayment interface.

It overrides the processPayment() method. Because authentication is not required here, we have not implemented the IOnlinePayment interface.

Every class correctly extends Payment's behavior while adhering to expectations.

Happy coding!!! 😊

in