Home » Software Development » SOLID – Liskov Substitution Principle

About Mohamed Sanaulla

SOLID – Liskov Substitution Principle

Liskov Substitution principle (LSP) states that,

Methods that use references to the base classes must be able to use the objects of the derived classes without knowing it

This principle was written by Barbara Liskov in 1988.

The idea here is that the subtypes must be replaceable for the super type references without affecting the program execution.

This principle is very closely related to Open Closed Principle (OCP), violation of LSP in turn violates the OCP. Let me explain:

If the subtype is not replaceable for the supertype reference, then in order to support the subtype instances as well we go ahead and make changes to the existing code and add the support. This is a clear violation of OCP.

This is mostly seen in places where we do run time type identification and then cast it to appropriate reference type. And if we add a new subtype implementation then we would have to edit the code to test for instance of for the new subtype.

Let me give a subtle example:

class Bird {
  public void fly(){}
  public void eat(){}
}
class Crow extends Bird {}
class Ostrich extends Bird{
  fly(){
    throw new UnsupportedOperationException();
  }
}
 
public BirdTest{
  public static void main(String[] args){
    List<Bird> birdList = new ArrayList<Bird>();
    birdList.add(new Bird());
    birdList.add(new Crow());
    birdList.add(new Ostrich());
    letTheBirdsFly ( birdList );
  }
  static void letTheBirdsFly ( List<Bird> birdList ){
    for ( Bird b : birdList ) {
      b.fly();
    }
  }
}

What do you think would happen when this code is executed? As soon as an Ostrich instance is passed, it blows up!!! Here the sub type is not replaceable for the super type.

How do we fix such issues?

By using factoring. Sometimes factoring out the common features into a separate class can help in creating a hierarchy that confirms to LSP.

In the above scenario we can factor out the fly feature into- Flight and NonFlight birds.

class Bird{
  public void eat(){}
}
class FlightBird extends Bird{
  public void fly()()
}
class NonFlight extends Bird{}

So instead of dealing with Bird, we can deal with 2 categories of birds- Flight and NonFlight.

How can we identify LSP violation?

Derived class may require less functionalities than the Base class, so some methods would be redundant.
We might be using IS-A to check for Super-Sub relationships, but LSP doesn’t use only IS-A, but it also requires that the Sub types must be substitutable for the Super class. And one cannot decide the substitutability of sub class in isolation. One has to consider how the clients of the class hierarchy are going to use it.

A detailed paper by Robert Martin on LSP.

Reference: SOLID- Liskov Substitution Principle from our JCG partner Mohamed Sanaulla at the “Experiences Unlimited” blog.

Related Articles :

Do you want to know how to develop your skillset to become a Java Rockstar?

Subscribe to our newsletter to start Rocking right now!

To get you started we give you our best selling eBooks for FREE!

1. JPA Mini Book

2. JVM Troubleshooting Guide

3. JUnit Tutorial for Unit Testing

4. Java Annotations Tutorial

5. Java Interview Questions

6. Spring Interview Questions

7. Android UI Design

and many more ....

 

Leave a Reply

Your email address will not be published. Required fields are marked *

*


Want to take your Java Skills to the next level?
Grab our programming books for FREE!
  • Save time by leveraging our field-tested solutions to common problems.
  • The books cover a wide range of topics, from JPA and JUnit, to JMeter and Android.
  • Each book comes as a standalone guide (with source code provided), so that you use it as reference.
Last Step ...

Where should we send the free eBooks?

Good Work!
To download the books, please verify your email address by following the instructions found on the email we just sent you.