Re: Clean Object Class Design -- Circle/Ellipse

"S Perryman" <q_at_deja.com> wrote in message news:<9pc243$hosvc$1_at_ID-75294.news.dfncis.de>...
> "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...
>
>
> 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

While I don't see the need for the new keyword, which would not apply in the dbms in any case, I would expect the output given.

> 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.

It should not involve any grief. If the language sufficiently distinguishes between values and variables, no grief should arise.

> 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.
>
> IMHO the "values vs variables" theme is quite a significant point.
> And provides another viewpoint on the problem fundamentals.
>
> As to whether it has enough to surplant/encompass other very good
> viewpoints (such as Wegner "subset subtyping" etc) , that is for
> debate.
>
> >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.

You raise an interesting question. What are the simple principles of OO? Does any consensus exist?

> >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.

What "objective" criteria would lead me to choose inheritance?

> >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" ... ??

Meyer, Stroustrup, Rumbaugh to name three. Received on Sun Oct 07 2001 - 01:45:13 CEST