The Liskov Substitution Principle is theL inSOLID object oriented design, and despite having one of the more intimidating sounding names of the 5 principles, it's actually pretty easy to wrap your head around.
It's so simple, in fact, that you're going to understand it in about 3 minutes.
What Is It?
The LSP, in simple terms, states that objects of the same superclass should be able to be swapped with each other without breaking anything.
If we have aCat
and aDog
class derived from anAnimal
class, any functions using theAnimal
class should be able to useCat
orDog
and behave normally.
Let's do an example!
Even that definition doesn't quite explain it very well, so let's put it into practice. All will become clear with the code.
In true OOP fashion, let's make anAnimal
superclass, and aDog
andCat
subclass and capture their favorite kinds of food.
publicstaticclassAnimal{publicStringfavoriteFood;publicAnimal(StringfavoriteFood){this.favoriteFood=favoriteFood;}}publicstaticclassDogextendsAnimal{publicDog(StringfavoriteFood){super(favoriteFood);}}publicstaticclassCatextendsAnimal{publicCat(StringfavoriteFood){super(favoriteFood);}}
Now we want to make a method that will let us give these cuties some treats. I don't want to put this method in theAnimal
classes though, because it'sme feeding the animals, not a behavior intrinsic to the animals. Something likeDog.feed
might get the point across, but I thinkfeed(Dog)
is better, don't you?
Let's make this method and call itGiveTreatTo
:
publicstaticvoidGiveTreatTo(Animalanimal){Stringmsg="You fed the "+animal.getClass().getSimpleName()+" some "+animal.favoriteFood;System.out.println(msg);}
See here thatGiveTreatTo
takes anyAnimal
as a parameter. Since ourAnimal
constructors assign the animal's favorite food, we can pretty much count on that data always being there.
This means we don't have to make a method for each animal, i.e.,GiveTreatToDog
andGiveTreatToCat
. Because we implemented LSP, we have one method. Let's see it in action:
publicstaticvoidmain(String[]args){Dogrover=newDog("bacon");Catbingo=newCat("fish");GiveTreatTo(rover);GiveTreatTo(bingo);}
Now, if we properly implemented the LSP, this program should run just fine. Let's check the output:
You gave the Dog some baconYou gave the Cat some fish
Amazing. Another benefit of this principal is we can add more and more subclasses ofAnimal
and theGiveTreatTo
method won't need any tinkering.
Wrap Up
Pretty non-intimidating right? As with many things in programming and computer science, the name belies its simplicity. Now, go out there and make your subclasses swappable, and thank Dr. Barbara Liskov for such a useful principle.
Top comments(9)

- LocationRemote
- EducationBachelor of Engineer - Computers
- WorkIndependent Consultant at Self-employed
- Joined
Can you expand your example that breaks LSP? I guess, that way entry level programmers will be able compare it.

- LocationFrýdek-Místek, Czechia
- WorkSoftware developer at Frýdek-Místek, Czechia
- Joined
Nice example of violation the LSP could be to make an animal purr. Everybody knows that only one who can purr in our domain are cats, that is why method Purr could not be in Animal class. Dog dont purr, dogs cant inherit such a behavior.

Although the two are related and support each other, it is possible to violate either of them while maintaining the other - have a look heresoftwareengineering.stackexchange.... for a worked example

I think this is more an example of the strategy pattern than the LSP. If I understand it correctly LSP is about not breaking the contract of superclass with the implementation of subclass.

- Email
- LocationOmaha, NE
- EducationBS CIS (2018), MS Software Engineering (2020), PhD Computer Science (in progress)
- PronounsHe/Him
- WorkSr. Software Engineer
- Joined
You're right. I would argue, though, that the strategy pattern adheres to the Liskov Substitution Principle and is thus a good example for conceptualizing the principle, especially quickly
For further actions, you may consider blocking this person and/orreporting abuse