TITLE: squares and rectangels and inheritance prevention methods


PROBLEM: mfinney@inmind.com writes:

While I haven't seen the "square-rectangle controversy", I presume it is
debating the question of whether you should do...

   class rectangle : public square {...};

or whether you should do...

   class square : public rectangle {...};

There is no controversy at all as I see it.  The latter is correct.

[ Great insight! :-< -adc ]


RESPONSE: mjmorris@synchlon.demon.co.uk

The latter does make more sense, but it depends what
you want to *do* with the rectangle.

What if it has member functions resizeX() and resizeY()?
What meaning do they have for a square? This is where the
"controversy" part starts: from there being possible
operations for a rectangle that don't carry across to a
square.

One answer to this is that you may not want to inherit
either from the other, depending on your problem domain.


RESPONSE: ellis@allegra.att.com (Margaret Ellis), 9 Aug 95

Member functions resizeX() and resizeY() in class rectangle
would be what Martin Carroll and I call "inheritance-preventing
member functions" in our discussion of obstacles to inheritability
in our book "Designing and Coding Reusable C++."  A solution we
suggest is a fine-grained inheritance hierarchy.  That is,
instead of:

	class rectangle {
		// ...
	public:
		void resizeX(int newX);
		void resizeY(int newY);
		// ...
	};

	class square : public rectangle {
		// What do we do when resizeX or resizeY is called?
	};

write this:

	class rectangle { /* No resize functions ... */ };

	class rectangle_with_resize : public rectangle {
		// ...
	public:
		void resizeX(int newX);
		void resizeY(int newX);
		// ...
	};

	class square : public rectangle { /* No worries about resizing */ };