Thread: Liskov substitution principle

I believe it has more to do with what in C++ is called Dynamic Binding. In that case, dynamic binding is an application of the Liskov Substituion Principle since dynamic binding allows you to use objects in a given hierarchy without caring about their specific types.

I have answered this elsewhere.

Subtyping and the LSP is the theoretical base on which the C++ derivation mechanism builds. This includes polymorphism.

However, C++ does not guarantee the LSP. You can still write hierarchies where it doesn't hold. It's the programmer's responsibility to avoid this.

Almost 100% of all samples of inheritance is showing valid LSP code - I don't think I've ever seen an example that doesn't.

As for an example that breaks LSP:

Code:

class base
{
public:
   virtual int foo() { ... };
};

class derived : public base
{
public:
    virtual int foo(int) { ... };
}

In this example, calling foo on a base-class pointer will call a different function than derived::foo(), which means that you don't get the same behaviour. In this case, because foo takes a new parameter in the derived class. It is possibly not a GREAT example, so if someone has a better example, please feel free to post one.

--
Mats

The classic "don't derive Square from Rectangle" counter-example is a case where the LSP is violated in inheritance.

matsp's example is incorrect. You can still use a derived just as a base, provided you use a base reference to refer to it, thus removing the name lookup rules.

Originally Posted by George2

I did some search. All I found from Google about "derive Square from Rectangle" are tutorials about how to use inheritance, seems legal and elegant.

The Rectangle derived square serves as an example of how careful one should be when building hierarchies on the "IS A" principle. Mathematically a square is a rectangle. However, often a square isn't a rectangle in a OO hierarchy.

The first clue you should get about a square not being a rectangle is the fact the square would only need to inherit one of setWeight() or setWidth() from rectangle. Inheriting both would not only be wasteful but also error prone since a class user would assume if he sets the width of the square, its weight will also be set, whereas this is not true of rectangles. There are obvious solutions to this, but with every one you find, you'll get more immersed in incorrect subtyping as other problems that are harder to solve start to emerge.

Meanwhile, another example where you are breaking the Liskov principle is when your member functions are depending on types:

Code:

void CShape::DrawShape(const CShape& obj) {
    if (typeid(obj) == typeid(CSquare))
         // call CSquare draw function
    else if (typeid(obj) == typeid(CCircle))
         // call CCircle draw function
}