Liskov Substitution Principle

The Open-Closed Principle is the heart of OO design. It advocates for abstraction to provide extensibility to any object, which is typically implemented using inheritance. Inheritance itself can lead to many possibilities, some of which can lead to wrong design. Liskov Substitution Principle (LSP) (pdf) is a guideline for inheritance design:

What is wanted here is something like the following substitution property: If for each object o1 of type S there is an object o2 of type T such that for all programs P defined in terms of T, the behavior of P is unchanged when o1 is substituted for o2 then S is a subtype of T.

It provides us the definition of a subtype or derived class. Programmatically, a function or method using object of a base class should behave the same when it is made to use object of a class derived from the base class. This falls inline with the notion that a subtype must confirm with the interface of its supertype. However, this is not true only syntactically. LSP tries to address the behavioral notion of subtyping.

The popular rectangle-square or ellipse-circle problems are result of violation of LSP. Lets take the example of the rectange square. By the “IS A” definition, square IS A rectangle. The behavior though can be different. The square can be considered as a special case of a rectangle where all the sides have same dimensions, and so can be derived from the rectangle. However, there can be some behavior of the rectangle that will fail with this special case. For example, when a rectangle is to be built with a certain area, there can be multiple combinations of the rectangle, but not with the square. This property of the rectangle that it can change its dimensions without changing the area cannot be addressed by the square. A functionality using this attribute of the rectangle will fail when it operates on a square.

In the real world parlance, rectangle photo frames with different dimensions can be manufactured for the same area, but it is not so with a square frame. This probably brings us to the essence of this

Square is a Rectangle, but a square object is not a rectangle object.

This stresses on the behavior of the square object rather than its structure. While only structure can be compatible, it is of importance that the behavior should also be compatible to follow the subtype-supertype relationship.

Change Inheritance Design

This does not mean that inheritance is faulty. What we realise here is that the rectangle and square have common behavior which can be modelled into a common base class. This will enable reuse of the common behavior and allow definition for specific behavior.

One thing that requires a mention here is that the above example of rectangle and square will fail if there is any functionality which is using the unequal dimension attributes of the rectangle. But, if the unequal dimension attributes are not being used, then LSP cannot be proved. However in such cases existence of the rectangle class itself can be questioned.

Design By Contract Methodology

As illustrated by Robert Martin (pdf), Design By Contract is related to LSP. The Design By Contract (DBC) defines that every software entity is obliged to continue providing service to other entities. The contract is defined by a set of preconditions and postconditions, which are programmatically translated into signature of the function/method. The caller satisfies certain preconditions upon which the callee with satisfy the postcondition. DBC says

When redefining a routine [in a derivative], you may only replace its precondition by a weaker one, and its postcondition by a stronger one.

In the rectangle-square example, the rectangle might have a method setDimensions(height, width), which for square can be translated to setDimensions(side). Here the square has replaced the rectangle’s precondition by a stronger one, causing violation of DBC. This can be used effectively to make sure that LSP is not violated.

Back to Design Principles.

Technorati tags: , , , , , ,

Copyright Abhijit Nadgouda.

Discussion [Participate or Link]

  1. Rashmi said:

    This is exactly what i want to read.

  2. Abhijit Nadgouda @ iface » Blog Archive » Design Principles said:

    […] Abhijit Nadgouda @ iface Software For Business, By Design « Liskov Substitution Principle Align Can Invalidate Your Post In Future » […]

  3. John Wilander said:

    Aren’t o1 and o2 mixed up in the last part of the property definition? I believe it should be “… the behavior of P is unchanged when o2 is substituted by o1 then S is a subtype of T”. Please correct me if I’m wrong.

  4. Abhijit Nadgouda said:

    Hi John,

    Thanks for pointing out, it should be “o1 is substituted for o2”. I have made the correction.

  5. OO Design Principles on iface thoughts said:

    […] Search « Liskov Substitution Principle | Align Can Invalidate Your Post In Future » March 24th, 2006 […]

  6. Alex Blewitt said:

    Firstly, the requirement was never proven; it was wouldn’t-it-be-nice-if. Secondly, it’s demonstrably false:

    new Object().equals(new Object())

    new String().equals(new String())

    The first evaluates to ‘false’ and the second evaluates to ‘true’. All we’ve done is substituted ‘String’ for ‘Object’.

    Therefore, a counter example has been found and it’s disproven.

  7. The Inheritance And Composition Duel | iface thoughts said:

    […] that the super class is not doing too much. It is not easy. No wonder there are principles like Liskov Substitution Principle (though it is as debated as inheritance […]

  8. naasking said:

    The first evaluates to ‘false’ and the second evaluates to ‘true’. All we’ve done is substituted ‘String’ for ‘Object’.

    Therefore, a counter example has been found and it’s disproven.

    What this shows is that the top type, ie. ‘object’, is poorly defined and should be avoided, not that the principle is not sound. I’m not a fan of inheritance in general, but this subtyping relationship is sound.

Say your thought!

If you want to use HTML you can use these tags: <a>, <em>, <strong>, <abbr>, <code>, <blockquote>. Closing the tags will be appreciated as this site uses valid XHTML.



Abhijit Nadgouda
iface Consulting
+91 9819820312
My bookmarks


This is the weblog of Abhijit Nadgouda where he writes down his thoughts on software development and related topics. You are invited to subscribe to the feed to stay updated or check out more subscription options. Or you can choose to browse by one of the topics.