Re: Clean Object Class Design -- Circle/Ellipse
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
