hi,i was recently asked during an interview if a circle class can inherit from an ellipse class. my thinking was that since a circle is a special case of an ellipse, then it should be allowed. but the interviewer said no. I find this to be subjective. Is there a right/wrong answer to this question?

QuoteOriginally posted by: billyx524hi,i was recently asked during an interview if a circle class can inherit from an ellipse class. my thinking was that since a circle is a special case of an ellipse, then it should be allowed. but the interviewer said no. I find this to be subjective. Is there a right/wrong answer to this question?In a previous life I worked in CAD and my company developed C++ and C# CADObject library that we used for all kinds of stuff. So we went through this whole discussion when developing the library.Where to star? First, some general issues:A. People confuse ISA (gen/spec) relationship with something elseB. ISA refers to base class B and derived class D. C. ISA is usually (incorrectly) done as base class B and object/instance of B that some people 'promote' to the status of a class (call it D).D. The "driver" B->D should be behavior, not structure.You may be making an error of judgment in one of A...C.Now for ellipse/circle; there's a lot of high school maths that we would like to use in CAD. In this regards Circle has much more functionality that Ellipse (intersection with circles, lines etc.). Here are the choices:I. Circle derived from Ellipse ("structure drives specialization" ==> wrong). Interviewer was correct.III. Create an Ellipse that uses a Circle; change coordinate to transform Ellipse to Circle, do the stuff on Circle and transform back (this is Composition).II. No class Circle, just class Ellipse (an object with axes a == b is just a square object and not a class).IV. Separate classes Ellipse and Circle (no relationship in principle).These are model. Which one is correct depends on your requirements! Maybe interviewer wanted to discuss the different scenarios.(Some) developers jump to conclusions => Use ISA based on inherited/specialized structure (WRONG), Use ISA based on inherited behaviour (GOOD).Languages that support interfaces don't have this problem. C++ does not support interfaces! //A good counterexample to case D above is Rectangle (width, height) and derived Square (width == height). QuizClasses Option, CallOption, PutOption, ShoutOption??

QuoteOriginally posted by: outrunWhy would you introduce a new circle type if you can simply set the ellipse parameters is such a way that the ellipse is a circle? Depending on the answer I'll have follow-up questions!Indeed! This is case II in my post.

QuoteOriginally posted by: outrunQuoteOriginally posted by: CuchulainnQuoteOriginally posted by: outrunWhy would you introduce a new circle type if you can simply set the ellipse parameters is such a way that the ellipse is a circle? Depending on the answer I'll have follow-up questions!Indeed! This is case II in my post.I was actually saying: only have an ellipse class, a circle is a special instance, no inheritance or extra types. Why would not stick with that? (the answer will lead the way to the OP I guess)Yes, I am actually agreeing with you! It is one answer and may or may not be the correct one depending on the requirements/contextThis solution is OK for Windows graphics but not for CAD because circle and circular arcs are vital. Then you need a class Circle unless you decide to do it in FORTRN ==> intersection(x1,y1,r1,x2,y2,r2,x3,y3,r3) (that's the way many CAD packages are implemented).

QuoteOriginally posted by: outrunQuoteOriginally posted by: CuchulainnQuoteOriginally posted by: outrunQuoteOriginally posted by: CuchulainnQuoteOriginally posted by: outrunWhy would you introduce a new circle type if you can simply set the ellipse parameters is such a way that the ellipse is a circle? Depending on the answer I'll have follow-up questions!Indeed! This is case II in my post.I was actually saying: only have an ellipse class, a circle is a special instance, no inheritance or extra types. Why would not stick with that? (the answer will lead the way to the OP I guess)Yes, I am actually agreeing with you! It is one answer and may or may not be the correct one depending on the requirements/contextThis solution is OK for Windows graphics but not for CAD because circle and circular arcs are vital.Exactly,the goal is to write a computer program and implement algorithms that fullfil requirement (various performance metrics, maintanability, etc), ..not to go about and try and to model the world, and try to do that with hierarchies for some arbitrary reason.Now, a possible requirement that could lead to a circle type could that you should use special routines for circle operations for perfomance reasons (speed and memory consumption). But why would that lead to inheritance? What's the reason to add an ellipse base class to the circle class?Good questions. I think I have answered them in my first post. A summary here:Quotetry and to model the worldDo not model the world, reduce the scope to CAD.QuoteBut why would that lead to inheritance?Not necessary, and probably wrong.QuoteWhat's the reason to add an ellipse base class to the circle classAlready answered.

A few semi-random thoughts on this:1. The scaling behavior is different for an ellipse and a circle. One can independently scale an ellipse in X and Y but not a circle. If a circle is to remain a circle, scaling in X results in scaling in Y, too.2. Rotating a circle about a point merely translates the circle in space (at worst, only the zero-angle point on the circle shifts). Rotating an ellipse causes significant changes in the bounding rectangle and complexity of the ellipse curve calculation.3. From a speed-of-computation POV, one might want to have independent algorithms for drawing circles, non-rotated ellipses, and rotated ellipses.4. Don't forget that the ellipse is a specific type of geometric figure, too. It is the curve in which the points have a constant sum-of-the-distances to exactly TWO focal points. The circle is the version/type with ONE focal point. And one can construct others with three, four, ..., N focal points. In that regard, both circles and ellipses are types of a more general class of figures although whether one implements that with inheritance is another matter.

QuoteOriginally posted by: Traden4AlphaA few semi-random thoughts on this:1. The scaling behavior is different for an ellipse and a circle. One can independently scale an ellipse in X and Y but not a circle. If a circle is to remain a circle, scaling in X results in scaling in Y, too.2. Rotating a circle about a point merely translates the circle in space (at worst, only the zero-angle point on the circle shifts). Rotating an ellipse causes significant changes in the bounding rectangle and complexity of the ellipse curve calculation.3. From a speed-of-computation POV, one might want to have independent algorithms for drawing circles, non-rotated ellipses, and rotated ellipses.4. Don't forget that the ellipse is a specific type of geometric figure, too. It is the curve in which the points have a constant sum-of-the-distances to exactly TWO focal points. The circle is the version/type with ONE focal point. And one can construct others with three, four, ..., N focal points. In that regard, both circles and ellipses are types of a more general class of figures although whether one implements that with inheritance is another matter.Very good. Even if ellipse and circle might the same, in the interest of maintainability it is a good idea to keep them apart. That's how we do it in CADObject library.I like your point 4 in particular.

Now that you've started, here's Square-Rectangle discussion.Same erroneous assumptions can be made here. At the end of the day, inheritance is only optimization (use HAS-A Composition).//thinking out loudclass SquareTheCircle : public Square, Circle {};Just kidding

QuoteOriginally posted by: CuchulainnNow that you've started, here's Square-Rectangle discussion.Same erroneous assumptions can be made here. //thinking out loudclass SquareTheCircle : public Square, Circle {};Just kiddingActually, squares and circles are variants of the same thing -- supercircles! The circle is the L-2 norm supercircle figure and the square is the L-∞ norm supercircle.

Actually, points (zero radius), line (infinite radius), circle ( 0 < rad < INF).And so on..