Re: Clean Object Class Design -- Circle/Ellipse

"Bob Badour" <bbadour_at_golden.net> wrote in message news:gHGt7.1518$rU1.108932233_at_radon.golden.net...

"James A. Robertson" <jarober_at_mail.com> wrote in message news:3BB6B750.2010903_at_mail.com...

>They relate to the topic under discussion: type inheritance. Because
>a variable is a different type than a value, Circle value is a
>subtype of Ellipse value while, at the same time, Circle variable is
>not a subtype of Ellipse variable. When people argue that Circle is
>not a subtype of Ellipse, they invariably apply LSP beyond its proper
>scope by assuming that values and variables are the same type.

Fair comment IMHO.

>[stuff snipped ... ]

>If one applies the SetMajorAxis operation to an ellipse variable that
>happens to contain a circle value, the language should allow the
>operation regardless.

>After the operation, the variable still contains an ellipse value,
>which is a valid value for the ellipse variable, even if it is no
>longer a circle value.

Do you mean something like this (assume circle inherits from ellipse) ...

/*1*/ circle c = new circle(radius=10) ;
/*2*/ ellipse e = c ;
/*3*/ print c.focusA() , c.focusB() ;
/*4*/ print e.focusA() , e.focusB() ;
/*5*/ e = e.setFocusA(123) ;
/*6*/ print c.focusA() , c.focusB() ;
/*7*/ print e.focusA() , e.focusB() ;

such that we get

3: 10,10
4: 10,10
6: 10,10
7: 123,10

With a suitable op signature for 5, we can achieve the above in OOP quite easily. Such an approach is not without potential grief (maintenance for one) , but acceptable.

JR>I find little merit in your definitions. They don't relate to
JR>solving any real problems in development; they don't relate to any
JR>useful information at all.

>Au contraire, subtype/supertype relationships arise in many, if not
>most, real problems in development. Any language that prohibits the
>user from modelling natural subtype/supertype relationships such as
>Circle/Ellipse interferes with development.

The reality is that the subset subtyping problem generally cannot be mapped (NOTE) *1:1* onto an OOP implementation. OO however (using simple principles etc) does allow us to realise reasonable solutions that maintain the relationship as modelled in the subject domain, in a form that is near-equivalent.

>For any such language, all inheritance will be arbitrary, ad hoc and
>unrelated to either the problem domain or the solution domain. No
>developer will ever have objective guidelines for when to use
>inheritance vs. roles, delegation etc.

Well some of us have given "objective" info to assist developers with the problem. So much so, I actually consider the impl/solution side to be a closed book nowadays.

>I find it very telling that almost every OO pundit has found it
>necessary to write an apologia explaining why the very real and
>natural subtype/supertype relationship between circle and ellipse
>does not apply in OO.

Who are these "pundits" to whom you refer ?? I have seen certain people show a fundamental misunderstanding of the problem, and then fall prey to that misunderstanding.

But "apologia" ... ??

Regards,
Steven Perryman Received on Tue Oct 02 2001 - 11:57:12 CEST