1

This is a fragment from "Exceptional C++" Item 24, Solution, first bullet from the bottom of the page:

Never use public inheritance to implement "IS-ALMOST-A." I've seen some programmers, even experienced ones, inherit publicly from a base and implement "most" of the overridden virtual functions in a way that preserved the semantics of the base class. In other words, in some cases using the Derived object as a Base would not behave quite the way that a reasonable Base client could expect. An example often cited by Robert Martin is the usually misguided idea of inheriting a Square class from a Rectangle class "because a square is a rectangle." That may be true in mathematics, but it's not necessarily true in classes. For example, say that the Rectangle class has a virtual SetWidth(int) function. Then Square's implementation to set the width would also naturally set the height so that the object remains square. Yet there may well exist code elsewhere in the system that works polymorphically with Rectangle objects, and would not expect that changing the width would also change the height. After all, that's not true of Rectangles in general! This is a good example of public inheritance that would violate LSP, because the derived class does not deliver the same semantics as the base class. It violates the key precept of public inheritance: "Require no more and promise no less."

I've tried to check it and I wrote:

// Square.cpp : Defines the entry point for the console application.
//

#include "stdafx.h"
#include <iostream>
using namespace std;
class Rectangle
{
private:
 unsigned width_;
 unsigned height_;
public:
 Rectangle(const unsigned width, const unsigned height):width_(width),height_(height)
 {/*Empty body*/ }
 unsigned GetWidth()const
 {
  return width_;
 }
 unsigned GetHeight()const
 {
  return height_;
 }
 virtual void SetWidth(const unsigned width)
 {
  width_ = width;
 }
 void SetHeight(const unsigned height)
 {
  height_ = height;
 }
 virtual ~Rectangle()
 {
  cout << "~Rectangle()" << '\n';
 };
};

class Square : public Rectangle
{
 using Rectangle::SetWidth;
public:
 Square(const unsigned width):Rectangle(width,width)
 {
 }
 void SetWidth(const unsigned width)
 {

  SetWidth(width);
  SetHeight(width);
 }
 ~Square()
 {
  cout << "~Sqare()" << '\n';
 }
};

int _tmain(int argc, _TCHAR* argv[])
{
 Rectangle** a = static_cast<Rectangle**>(operator new (sizeof(Rectangle) * 2));
 a[0] = new Rectangle(10,10);
 a[1] = new Square(5);
 Rectangle* r = a[0];
 cout << r->GetHeight() << "\t" << r->GetWidth() << '\n';
 r = a[1];
 cout << r->GetHeight() << "\t" << r->GetWidth() << '\n';
 r = a[0];
 r->SetWidth(20);//here I'm setting just width for a Rectangle
 cout << r->GetHeight() << "\t" << r->GetWidth() << '\n';
delete a[1];
delete a;
     return 0;
    }

As for me inheriting Square from Rectangle works as intended. So where am I making mistake and do not understand what is said in this bullet?
Thanks

There is nothing we can do
  • 23,727
  • 30
  • 106
  • 194
  • Similar to this question: http://stackoverflow.com/questions/1030521/is-deriving-square-from-rectangle-a-violation-of-liskovs-substitution-principle – Philip Potter Aug 28 '10 at 21:50

2 Answers2

5

The point is that the semantics for the Square class are different from those of the Rectangle class. Say you have a general utility function like this:

void doubleArea(Rectangle &rect) {
  rect.setWidth(rect.getWidth() * 2);
}

The intention is that a call to that function will double the area (width × height) of the given Rectangle.

With your derived Square class, you can now do something like this:

Square sq(1);
doubleArea(sq);

Suddenly sq has four times the area then before the call. You only intended to double the area, but got a wrong result.

Since Square doesn't have the exact same semantics as Rectangle, sometimes doing things that are ok for rectangles will not work for squares. Therefore it's not a good idea to claim that Square is a Rectangle by deriving one from the other, since the derived class can't fulfill all the requirements/promises made by the base class.

For more on this topic also see the C++ FAQ Lite entry "Is a Circle a kind-of an Ellipse?".

sth
  • 222,467
  • 53
  • 283
  • 367
0

Your code is fine. What the bullet is suggesting is that someone may write some code that depends on the height of a rectangle remaining unchanged across a SetWidth call:

int old_height = r->GetHeight();
r->SetWidth(100);
assert old_height == r->GetHeight();

This code would fail with your implementation of SetWidth in Square.

Keith Randall
  • 22,985
  • 2
  • 35
  • 54
  • The code is not fine, `Square` violates the contract that `Rectangle` makes. – Philip Potter Aug 28 '10 at 21:52
  • The code is fine. Nowhere does he violate any contract that Rectangle makes, as Rectangle makes no contract. The spec of Rectangle::SetWidth needs a guarantee like "does not change height". Of course, we often assume this, but I would contend that without that explicit spec, it is my code that is wrong (as is the other example code in other answers to this question). – Keith Randall Aug 28 '10 at 22:12
  • A spec doesn't have to be explicit to be a spec. You can't make everything explicit. – Philip Potter Aug 28 '10 at 22:15
  • I suppose not. And to be clear, I wouldn't want to use a Rectangle class that didn't have that guarantee. But the OP's code doesn't rely on any guarantee, he needs code like mine above to create the described inheritance bug. – Keith Randall Aug 28 '10 at 22:34