Re: Clean Object Class Design -- Circle/Ellipse

"S Perryman" <q_at_deja.com> wrote in message news:<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.

I do not see how your example supports this last statement.

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

I disagree. If the language sufficiently distinguishes between values and variables, no grief will arise. (At least, no grief caused by modelling natural subtypes as subtypes.)

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

I fail to see how any of these types make things any more tricky. A square is both a rectangle and a rhombus. A rectangle is a parallelogram. A rhombus is both a parallelogram and a kite. A parallelogram is a quadrilateral. A trapezoid is a quadrilateral. A kite is a quadrilateral. A quadrilateral is a polygon. etc.

By (indirect) type inheritance, a square is also a kite, a parallelogram, a quadrilateral and a polygon etc.

> Also, the issue in the OOP context is IMHO more about values and
> representation of values, than values and variables.

In database management, we must keep representation independent of type in order to provide physical independence.

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

When I search for "perryman wegner square" on google, the search returns exactly 14 hits -- none of which have anything to do with OOP. I can only assume you did not attempt the search prior to suggesting it.

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

I finished my Google browsing. I am not sure how the "Guildford County property records" or the "Iowa State Fair Blue Ribbon Foundation" clarify anything about type inheritance.

Incidentally, I have never discounted inheritance as a solution to these types of problems. I think that type inheritance is the solution to these types of problems. However, I do not think that any current OO programming language adequately or properly supports type inheritance. The type of a variable is different from the types of the values it can contain.

One needs to differentiate between problems in a specific language (or in a specific language implementation) and problems in concept.

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

The problems are inherent to the deficiencies of the programming languages used. The problems are not inherent to type inheritance.

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

If the principles are very simple, one should be able to enumerate them (at the very minimum.)

(Incidentally, I started a new thread to discuss language design principles without the above baggage.) Received on Thu Oct 18 2001 - 04:31:28 CEST