Liskov substitution principle

Hello everyone,


I am learning Liskov substitution principle,

http://en.wikipedia.org/wiki/Liskov_...tion_principle

But the description is not common senses. Now I understand this principle to be, if we have some methods in base class, then we also need to implement the methods in derived class. My understanding correct? Anything else missing?


thanks in advance,
George

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.

Thanks Mario,


In your senses, Liskov Substituion Principle is the same as polymorphic? If not, what in your senses is the differences? Could you provide some pseudo code about what code follows LSP pattern and what code does not follow?

Quote:

---

Originally Posted by Mario F.

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.

---

regards,
George

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.

Thanks CornedBee,


Can you show me a sample which is not LSP and a sample which is LSP please? Good to learn by sample.

Quote:

---

Originally Posted by CornedBee

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.

---

regards,
George

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.

Thanks CornedBee,


1.

Quote:

---

Originally Posted by CornedBee

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

---

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. It is appreciated if you could show what do you mean "derive Square from Rectangle" counter-example? A link or some pseudo code?

2.

Quote:

---

Originally Posted by CornedBee

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.

---

You mean call base::foo from derived class? If I am wrong, please correct me. :-)


regards,
George

Quote:

---

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
}

---