Liskov Substitution Principle

The following two tabs change content below.
Prasad Kharkar is a java enthusiast and always keen to explore and learn java technologies. He is SCJP,OCPWCD, OCEJPAD and aspires to be java architect.

Latest posts by Prasad Kharkar (see all)

Continuing our series about design principles, we will look into another important design principle and understand using violation of liskov substitution principle.

Liskov Substitution Principle:

Liskov Substitution Principle states that Subtypes must be substitutable for their base classes.

At first it does not seem like very difficult to understand. We know that derived classes and base classes talk about inheritance. Yes, Liskov Substitution Principle is about inheritance, but about well designed inheritance. You should be able to substitute subclass object for base class without things going wrong.To understand correctly, let us see violation of liskov substitution principle.

Violation of Liskov Substitution Principle:

Consider Graph2D class which has a draw() method that can plot a point in 2 dimensional space. The class is as below


Now we have a new requirement, we want to be able to draw a 3D graph. Now 3D graph simply has a z co-ordinate, right ? It can inherit functionality to draw 2d graph from Graph2D itself, seems quite right. Why not extend Graph2D class? Let us try it.


Now you can call using Plotter class

Seems quite right, we are calling draw(int x, int y, int z) method on a Graph3D object which prints 3D point. so where is the problem?

Graph3D extends Graph2D and hence it also has draw(int x, int y) method,  and the call graph.draw(4 , 4); is also valid and it will print

drawing a 2D co-ordinate

Liskov Substitution Principle states that subtypes must be substitutable for their base classes. so when we call graph.draw(4.4) its not really drawing a 3D graph and it does not make sense at all. it is violation of liskov substitution principle.

so what is the solution now? we can achieve this using delagation.

  When you  hand over the responsibility of a particular task to another class or method, then it is called delegation. 

We can create association between Graph3D and Graph2D such that Graph3D delegates the functionality of drawing 2 d co-ordinates to Graph2D. We create instance variable of Graph2D in Graph3D.


Now this prints,

drawing a 2D co-ordinate
drawing a 3D co-ordinate

Now you cannot call draw(int x, int y) method on a Graph3D object which helps in reducing confusing code and solving violation of liskov substitution principle

I hope this article helped in understanding violation of liskov substitution principle and how it can be solved using delegation.


Share Button

3 comments for “Liskov Substitution Principle

  1. sham
    June 16, 2016 at 12:50 pm

    This is example is not correct as Graph3D is not expending the super class in the modified code at
    the bottom

    • June 16, 2016 at 1:54 pm

      Hi Sham, thank you for your comment. Please note that the example above shows that Graph2D and Graph3D are not suitable for Liskov Substitution Principal. To solve this problem, the example uses Delegation. Graph3D is not a substitute for Graph2D. As this example is violating Liskov Substitution Principle, it is solved using Delegation where Graph2D HAS-A Graph2D.

    • Nyng
      April 4, 2017 at 10:10 am

      The Graph3D need Graph2D to complete a part of its task, Graph3D:draw(x, y, z).
      This means that Graph3D and Graph2D work like a team, the former need a hand from the latter.

      If you let SomeClass extend Graph2D, you’re actually make a stronger version of Graph2D.
      Then SomeClass can substitute Graph2D completely. But in this example, the author want to re-use the Graph2D.

Leave a Reply

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