Liskov Substitution Principle

This article explains the Liskov Substitution Principle.

Read below before reading blow one 

 
Liskov Substitution Principle – is one of the SOLID principles defined by Barbara Liskov. Principle is based on the parent-child relationship in other words inheritance features of OOD (Object Oriented Design). Principle says “When class S is a subtype of class T then an object of type T can be replaced by an object of type S without affecting functionality/correctness of the implementation or program”.

In simple words it says “Places in implementation (Class/Function) that use a base class, in other words consume a service of a base class, must work correctly when the base class object is replaced by a child class (derived class) object.”

Liskov Substitution Principle in Real life

The following is an example of an electric bulb that actually violates substitution. When the bulb fails it is replaced with a new bulb. Here in this example the old bulb is replaced with the new bulb.

Perfect Substitution



Note:

Here in this example in the family of bulbs, considering the old bulb to be a parent of all bulb types and a CFG bulb is a child of the same family inherited from it.

When one replaces a failed bulb, in other words in programming terms substitutes the old with the new, it must provide light that is provided by the old bulb, in other words works without affecting correctness or functionality (provides a constant light in the house). In the preceding example the substitution worked perfectly since there is no modification in functionality.

Violation Example



The preceding image shows the violation of the principle. Since replacing with a decoration bulb (that provides light in the form of decoration) instead of a bulb meant for just providing light in the house. That actually is a violation in the sense of modifying the functionality because a decoration bulb does not provide the same functionality for the consumer.

Example of not following Principle in Application Development

Continuing with bank savings account that is already explained in previous articles about the Open-Closed Principle.

  1. Interface ISavingAccount  
  2. {  
  3.    //Other method and property and code  
  4.    bool Withdrwal(decimal amount);  
  5. }  
  6.   
  7. Public Class RegularSavingAccount : ISavingAccount  
  8. {  
  9.   //Other method and property and code related to Regular Saving account  
  10.   
  11.    Public bool Withdrwal ()  
  12.   {  
  13.     Decimal moneyAfterWithdrawal = Balance-amount;  
  14. if(moneyAfterWithdrawal >= 1000)  
  15. {  
  16.     //update balace   
  17.     return true;  
  18. }  
  19. else  
  20.   return false;  
  21.   }  
  22. }  
  23.   
  24. Public Class SalarySavingAccount : ISavingAccount  
  25. {  
  26.   //Other method and property and code related to Salary Saving account`  
  27.    Public bool Withdrwal ()  
  28.   {  
  29.     Decimal moneyAfterWithdrawal = Balance-amount;  
  30. if(moneyAfterWithdrawal >= 0)  
  31. {  
  32.     //update balace   
  33.     return true;  
  34. }  
  35. else  
  36.   return false;  
  37.   }  
  38. }  
  39. Public Class FixDepositSavingAccount : ISavingAccount  
  40. {  
  41.   //Other method and property and code related to Salary Saving account`  
  42.    Public bool Withdrwal ()  
  43.   {  
  44.     Throw New Excpetion(“Not supported by this account type”);  
  45.   }  
  46. }  
In the preceding code the IsavingAccount interface is implemented by a different kind of savings account of the bank, like Regular, Salary and FixDeposit savings account.

But as per the banking rules, a FixDeposit savings account doesn't provide a withdrawal facility whereas another bank account might provide a withdrawal facility.

So the developer might write code to raise an exception when an attempt is made to withdraw from a FixDeposit savings account.

Now consider the following method in a class calling a withdrawal by casting the actual object to the parent class type.
  1. Public class AccountManager  
  2. {  
  3. Public bool WithdrawFromAccount(IsavingAccount account)  
  4. {  
  5.     account.Withdraw(amount);  
  6. }  
  7. }  
The following code calls the method,
  1. //works ok  
  2. AccountManager.WidhdrawFromAccount(new RegularSavingAccount());  
  3. //works ok  
  4. AccountManager.WidhdrawFromAccount(new SalarySavingAccount());  
  5. //throws exception as withdrawal is not supported  
  6. AccountManager.WidhdrawFromAccount(new FixDepositSavingAccount());  
Violation of Liskov Substitution Rule

So the preceding code breaks the Liskov Substitution rule since the inherited FixDepositSavingAccount class is modifying the functionality of the withdrawal. Because the savings account should provide functionality to withdraw an amount without throwing any error.

How to stop violating the rule

To stop violating the rule one must verify the inheritance tree, in other words child classes inherited from the parent class should not break the functionality when the child class object replaces the parent class object.

So the class must inherit from the proper parent class in such a way that when the child class replaces the parent, it doesn't break the actual functionality provided by the parent class.

Note

It's not always true that one must make changes in the inheritance tree but making changes at the class and method level also resolves problems. To get such kind of example click on the link: Object Menter (Square and rectangle example).



In the preceding image the new classes WithWithdrawal and WithoutWithdrawal are created and the child classes are inherited from the respective parent class.

So in the preceding code:
  1. Interface ISavingAccount  
  2. {}  
  3. Public Class SavingAccountWithWithdrawal : ISavingAccount  
  4. {  
  5.     Public virtual bool Withdrwal () {}  
  6. }  
  7. Public Class SavingAccountWithoutWithdrawal : ISavingAccount  
  8. {  
  9. }  
  10. Public Class RegularSavingAccount : SavingAccountWithWithdrawal  
  11. {   
  12.   Public bool Withdrwal ()  
  13.   { //implementation  
  14.   }  
  15. }  
  16. Public Class SalarySavingAccount : SavingAccountWithWithdrawal  
  17. {   
  18.   Public bool Withdrwal ()  
  19.   {//implementation  
  20.   }  
  21. }  
  22. Public Class FixDepositSavingAccount : SavingAccountWithoutWithdrawal  
  23. {  
  24. }  
Now using it:
  1. Public class AccountManager  
  2. {  
  3. Public bool WithdrawFromAccount(SavingAccountWithWithdrawal account)  
  4. {  
  5.     account.Withdraw(amount);  
  6. }  
  7. }  
Now the following code to call method:
  1. //works ok  
  2. AccountManager.WidhdrawFromAccount(new RegularSavingAccount());  
  3. //works ok  
  4. AccountManager.WidhdrawFromAccount(new SalarySavingAccount());  
  5. //compiler gives error   
  6. AccountManager.WidhdrawFromAccount(new FixDepositSavingAccount());  
Disadvantage of not following the Liskov Substitution Principle

  • Developed code throws a run time error or exception or also might not work as expected and that leads to program failure or incorrect results.
  • The preceding discussion shows an example of throwing an exeption by a child class for a not supported method.
  • Read link: Object Mentor that shows an example (square and rectangle example) of giving incorrect results when not following the principle.
So the biggest advantage of not following this rule is: it causes problems at runtime rather than causes application failure or incorrect results.
 
Further Read