What is the Liskov Substitution Principle(LSP)?

The Liskov Substitution Principle(LSP) is one of the design principles of SOLID which is defined as “if S is a subtype of T, then objects of type T may be replaced with objects of type S without altering any of the desirable properties of the program”.

To understand this clearly, let us consider the following scenario.

You are tasked with building a user management system as part of a project for a client, whose only users are their employees. The requirements given to you are simple. The system should allow the retrieval of the profile of employees and additionally, allow them to login into the system. Following the requirements, you derived an Employee class whose functionality includes being able to retrieve their profile and allowing them to login.

Figure 1. Employee class.

A few weeks later, the client decided that employees should be blocked(not able to login) if they are no longer with the company. However, the system should still be able to unblock the employee if deemed necessary. Viewing it as an extension to the current Employee class, a new BlockedEmployee class was created as an extension from the current Employee.

Figure 2. BlockedEmployee inheriting from Employee class.

This is a clear violation of the Liskov Substitution Principle since when we substitute Employee with a BlockedEmployee, the employee will not be able to login into the system since the BlockedEmployee login function(that denies login access to the user) overrides the Employee login function. This can lead to catastrophe such that mistakenly substituting an Employee with a BlockedEmployee, can potentially block users from logging into the system.

Applying Liskov Substitution Principle

For the Liskov Substitution Principle to hold, the child classes have to adhere to the existing functionality of the parent class. This means that the child class should not change the behaviour of the existing functions of the parent class.

The example above can be fixed by simply introducing a User class where both the Employee class and BlockedEmployee class will inherit from. In addition, we will omit both the login and unblock functionality from the User class and will only implement them in their relevant child classes.

Figure 3. Employee and BlockedEmployee inheriting from User class

It is clear to see that now, in order for a user to login, they must be an Employee as the login functionality only resides within the Employee class and similarly, for a blocked employee to be unblocked, they must be a BlockedEmployee. Since both child classes do not change the expected behaviour of their parent and we are able to substitute the User class with either an Employee or BlockedEmployee, the Liskov Substitution Principle now holds.

Pros and Cons

Let us now review some pros and cons related to applying the Liskov Substitution Principle.

Pros

• Ensures intended functionality
• Easier maintenance
• Increases cohesiveness

Cons

• Requires new classes to be implemented
• Can be costly to implement on existing systems

From the example given above, we can see how LSP prevents bugs arising due to the weak definition of the parent-child relationship. Also, applying LSP to a component makes it easier for it to be maintained since related functionality is being grouped together in their related parent or sub-class.

However, we must be mindful that applying LSP to existing systems may be costly as components and their dependencies will require changes to be made. Therefore, we must always consider the cost, time and quality associated with the change, before implementing it.

Summary

From the example above, we can see how easy it is for our program to fail if we are not careful in ensuring the intended behaviour of our classes. LSP is one of the ways that help to maintain this ‘contract’ between child and parent class relationships that guards our program against such scenarios. Therefore, following the SOLID principles such as LSP, can prevent problems that might arise in the near future.