Re: Clean Object Class Design -- Circle/Ellipse

From: Cagdas Ozgenc <co19_at_cornell.edu>
Date: Mon, 6 Aug 2001 09:43:22 +0300
Message-ID: <9kleou$g4l$1_at_news01.cit.cornell.edu>


> In "Type Inheritance: Is a Circle an Ellipse?" on www.dbdebunk.com
> Date insists:
> "As already indicated, it's my position that a circle categorically is
> an ellipse in the real world -- to be specific, it's an ellipse in
> which the two semiaxes coincide in the radius (equivalently, it's an
> ellipse for which a=b). In my opinion, therefore, any "model" of
> inheritance in which type CIRCLE is not considered to be a subtype of
> type ELLIPSE can hardly be said to be a good model of reality."
>
> Is that a MAY (allow) or a MUST(require)?
> Hint; what does *categorically* mean?

The similar discussion was on "Is square a rectangle?" My conclusion was it totally depends on how you model the class hierarchy. For example if I model the Ellipse class like the following:

class Ellipse {
protected:

    float a;
    float b;
public:

    /* pre: oldB = getAxisB();

  • post: newA == getAxisA() ; oldB() == getAxisB(); */ void setAxisA(float newA) { a = newA; }

    /* pre: oldA = getAxisA();

  • post: newB == getAxisB() ; oldA() == getAxisA(); */ void setAxisB(float newB) { b = newB; }

    float getAxisA() { return a; }
    float getAxisB() { return b; }
}

Now there is no way you can inherit Circle from this perfectly valid Ellpise class, because you cannot make the two axises equal to each other without violating the pre/post conditions stated by the base class. By definition of inheritance, the derived classes can only strengthen the post condition of the methods that they override. Hence a Circle derivation is not possible from the above Ellipse class. Received on Mon Aug 06 2001 - 08:43:22 CEST

Original text of this message