Re: Clean Object Class Design -- Circle/Ellipse
Date: Tue, 9 Oct 2001 11:03:44 +0100
Message-ID: <9puh2f$kisk6$1_at_ID-75294.news.dfncis.de>
"Bob Badour" <bbadour_at_golden.net> wrote in message news:cd3b3cf.0110061545.7a2532b_at_posting.google.com...
>>"S Perryman" <q_at_deja.com> wrote in message
>>news:<9pc243$hosvc$1_at_ID-75294.news.dfncis.de>...
>> /*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.
I introduced the example specifically to give those in the 'circle/ ellipse violates the LSP' camp more food for thought. :-)
Emphasising that choice of operation signature is actually a far more significant factor in LSP violation than the fact that a (subset) subtype hierarchy exists.
>> 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.
Grief will creep in if the subtype hierarchy gets more interesting.
Circle/ellipse is quite trivial. When I consider the problem for a subtype hierarchy defining quadrilaterals (squares, rectangles, trapezia, kites, rhombus etc) , things get much more tricky in an OOP context.
Also, the issue in the OOP context is IMHO more about values and representation of values, than values and variables.
>>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?
To see how some simple principles can assist the OOP world in achieving the above, search Google for "perryman, wegner, square" .
DB>For any such language, all inheritance will be arbitrary, ad hoc DB>and unrelated to either the problem domain or the solution domain. DB>No developer will ever have objective guidelines for when to use DB>inheritance vs. roles, delegation etc. SP>Well some of us have given "objective" info to assist developersSP>with the problem. So much so, I actually consider the impl/ SP>solution side to be a closed book nowadays.
>What "objective" criteria would lead me to choose inheritance?
Once you've done your Google browsing, IMHO it should be clear(er) as to why inheritance doesn't have to be discounted as a solution to these types of problem.
>>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.
Well, I looked at their books (Meyer - OOSC 2e section 24.5, Stroustrup - C++ programming language 3e p703, Rumbaugh - OOAD p63) , notably all of which chose circle/ellipse for discussion.
I saw nothing written there to suggest that a "natural" subtype relationship does not "apply" to OO, but plenty informing us that any attempts to do so are not without problems.
What they haven't done is given us guidance on how to overcome such problems in an OOP context. Fortunately some of us through background and experience, have discovered how to resolve the problem with some very simple principles.
Regards,
Steven Perryman
Received on Tue Oct 09 2001 - 12:03:44 CEST