Solid Principle : Liskov Substitution Principle

Overview

The Liskov Substitution Principle (LSP) is a valuable SOLID principle in object-oriented programming. It helps ensure that code is well-structured and robust by encouraging developers to create classes that are highly interchangeable and maintainable. Essentially, the principle promotes the idea that if a class is a subclass of another class, it should be able to replace its parent class without any unexpected errors or side effects. By adhering to LSP, developers can create code that is more flexible and easier to maintain in the long term.

Let's explore a practical scenario that effectively demonstrates the Liskov Substitution Principle (LSP) in relation to various types of banking accounts.

Scenario: Banking Accounts

Imagine that you are designing a comprehensive banking system that provides a range of financial services to its clients. Initially, the system supports two types of accounts: SavingsAccount and CheckingAccount. While these two accounts are sufficient to serve the basic banking needs of most clients, you realize that there are some clients with more complex financial requirements. To cater to such clients, you introduce a more specialized type of account called BusinessAccount.

The BusinessAccount is designed to provide advanced financial services, such as invoicing, payroll processing, and tax reporting, to businesses. You understand that clients may want to switch between different types of accounts based on their changing financial needs. Therefore, you strive to ensure that the banking system is flexible enough to allow clients to substitute any type of account without affecting the correctness of the banking system.

In other words, you want to ensure that the banking system can handle a seamless transition between different types of accounts without any errors or discrepancies. This is crucial to maintain the trust and satisfaction of the clients, who would expect a banking system that is efficient, reliable, and easy to use.

Benefits:

By following LSP, developers can achieve a number of important benefits. For example, LSP promotes the development of code that is more reusable, maintainable, and extensible. It also encourages developers to create hierarchies of related classes that can be used to build scalable systems over time.

Another key advantage of LSP is that it promotes abstraction, design consistency, modularity, and simplicity in testing. By creating well-defined class hierarchies that adhere to LSP, developers can simplify the process of testing their code, reduce the likelihood of errors, and improve the overall quality of their software systems.

Overall, LSP is an essential principle for any developer who wants to create scalable and maintainable software systems that can evolve over time. Whether you're building a simple application or a complex enterprise system, following LSP can help you achieve better results and avoid common pitfalls in software development.

Without LSP Code

public class Account
{
    public virtual void Deposit(double amount)
    {
        // Generic deposit logic
    }

    public virtual void Withdraw(double amount)
    {
        // Generic withdrawal logic
    }

    public virtual double GetBalance()
    {
        // Generic balance retrieval logic
        return 0.0;
    }
}

public class SavingsAccount : Account
{
    // Specific implementation for savings account
}

public class CheckingAccount : Account
{
    // Specific implementation for checking account
}

// Later, introducing a new account type without adhering to LSP
public class BusinessAccount : Account
{
    // Specific implementation for business account
}

In the context of object-oriented programming, the Liskov Substitution Principle states that subtypes should be interchangeable with their base types without altering the correctness of the program.

However, in a specific case where the BusinessAccount class is derived from the Account class, it may introduce additional behaviors that are not applicable to other account types. This violates the Liskov Substitution Principle, as clients who expect an Account may encounter unexpected behavior when dealing with a BusinessAccount. The introduction of non-standard behaviors in a subtype can cause confusion and make the code more challenging to maintain. Therefore, it is essential to ensure that subtypes do not introduce behaviors that are not compatible with the base type..

With LSP:

public abstract class Account
{
    public abstract void Deposit(double amount);

    public abstract void Withdraw(double amount);

    public abstract double GetBalance();
}

public class SavingsAccount : Account
{
    // Specific implementation for savings account
}

public class CheckingAccount : Account
{
    // Specific implementation for checking account
}

public class BusinessAccount : Account
{
    // Specific implementation for business account
    // Inherits and overrides methods, but still adheres to the base class contract
    public override void Deposit(double amount)
    {
        // Business account deposit logic
    }

    public override void Withdraw(double amount)
    {
        // Business account withdrawal logic
    }

    public override double GetBalance()
    {
        // Business account balance retrieval logic
        return 0.0;
    }
}

The upgraded version of the Account class has been designed to offer enhanced functionality, whereby each specific account type (SavingsAccount, CheckingAccount, BusinessAccount) inherits from the base Account class which is now abstract. This design allows each subclass to provide its own implementation of deposit, withdrawal, and balance retrieval methods. This enables customers to substitute any type of account without violating the expected behavior specified in the base class. It also ensures that the BusinessAccount class still adheres to the contract outlined by the Account base class. This new and improved design is highly beneficial to customers as it provides them with greater flexibility and choice when it comes to managing their accounts.

Main Functionality

class Program
{
    static void Main(string[] args)
    {
        Account savingsAccount = new SavingsAccount();
        Account checkingAccount = new CheckingAccount();
        Account businessAccount = new BusinessAccount();

        // Clients can substitute any type of account
        savingsAccount.Deposit(1000.0);
        checkingAccount.Withdraw(200.0);
        double businessBalance = businessAccount.GetBalance();
    }
}

By following the Liskov Substitution Principle in this banking system example, you ensure that adding a new type of account (BusinessAccount) does not break the expected behavior when interacting with the more general Account type. This promotes flexibility, maintainability, and correctness in the design of the banking system

Thank you for reading, and feel free to comment or connect with me LinkedIn and GitHub .

*Click here for *

Single Responsibility Principle
Open/Closed Principle