Contents Up << >>

Are there other options to the "Circle is/is not kind-of Ellipse" dilemma?

If you claim that all Ellipses can be squashed asymmetrically, and you claim that Circle is a kind-of Ellipse, and you claim that Circle can't be squashed asymmetrically, clearly you've got to adjust (revoke, actually) one of your claims. Thus you've either got to get rid of " Ellipse::setSize(x,y)", get rid of the inheritance relationship between Circle and Ellipse, or admit that your "Circle"s aren't necessarily circular.

Here are the two most common traps new OO/C++ programmers regularly fall into. They attempt to use coding hacks to cover up a broken design (they redefine Circle::setSize(x,y) to throw an exception, call "abort()", or choose the average of the two parameters, or to be a no-op). Unfortunately all these hacks will surprise users, since users are expecting "width() == x" and "height() == y".

The only rational way out of this would be to weaken the promise made by Ellipse's "setSize(x,y)" (e.g., you'd have to change it to, "This method might set width() to x and height() to y, or it might do nothing"). Unfortunately this dilutes the contract into dribble, since the user can't rely on any meaningful behavior. The whole hierarchy therefore begins to be worthless (it's hard to convince someone to use an object if you have to shrug your shoulders when asked what the object does for them).

  • Inheritance: Access rules