NetNews Usenet Archive 1992 #19/NN_1992_19.iso/spool/comp/object/3380

Text File | 1992-09-02 | 4.3 KB | 86 lines

Newsgroups: comp.object
Path: sparky!uunet!gumby!wupost!rice!cs.rice.edu!mcw
From: [e-mail] (Michael Wirth)
Subject: Re: Object-Oriented Methodologies - Class Specifications
Message-ID: <[e-mail]>
Summary: Generic functions make factoring behavior easier
Sender: [e-mail] (News)
Organization: Rice University, Houston
References: <[e-mail]> <[e-mail]> <[e-mail]>
Date: Wed, 2 Sep 1992 15:40:55 GMT
Lines: 73


"Ronald C. Schultz" <[e-mail]> writes:

In Rumbaugh's OMT text he
provides a class specification for a circle on page 290.  I quote:
...
        Public Methods:
                draw (Window) - draws a circle in the window
                intersectLine (Line): Set of Points - finds the
intersection of a line and a circle, returns set 0-2 points

This class specification screams of unnecessary object coupling.  Why,
for instance, should a circle need to be aware of the existence of
lines? or of the existence of windows?  To me, this class violates the
very concept of a circle as defined in any geometry text.

My question - can someone please explain to me why they feel this class
is legitimate, (or illegitimate for that matter).  Why isn't the draw
operation and intersectLine operation more appropriately assigned to the
drawing application itself, rather than the circle?  Rumbaugh's OMT as
well as some other OO methods seem to directly oppose long-term reuse of
the method's analysis and design products.  Are others encountering the
same issues?
--------------------------------------

It's very interesting to note how our use of language (both programming and
human) influences our thinking.  In particular, use of a message passing style
of OOP, where methods are "owned" by their target class, leads to the curious
asymmetry noted above.  In a language, CLOS, which uses generic functions and
multi-methods (i.e., which specialize on more than one argument), this
asymmetry can be avoided, i.e., we would define a generic function, INTERSECT,
which would specialize on both its arguments.  One specific method which it
would be useful to define then would specialize on lines and circles:
        INTERSECT((x, LINE) (y, CIRCLE))
Who "owns" this method?  Probably some higher level entity, like the "geometry
package".

I find this discussion to be "deja vu all over again" and to contain several
ironies:
1) In a very interesting panel discussion at the '89 OOPSLA, Deutsch, Kiczales
and Stroustrup were each asked to talk about one of the other's languages.
Stroustrup discussed CLOS and used the example of INTERSECTING OBJECTS to show
why he thought CLOS's generic functions were useful.

2) One of the KEY IDEAS in Rumbaugh, et al's book is that relationships between
objects, i.e., associations, are often important entities in their own right,
and need to be treated separately.  I find it interesting that the cited
example from the same book doesn't recognize or take advantage of that.

Subsequent comments to the original message contained some interesting issues:
1) Things only get interesting when you have lots of classes, i.e., lots of
possible types of relationships.  Agreed.  Just like the real world, isn't it?
It's in modeling these relationships where our applications gain their real
power.

2) What about the explosion of pair-wise methods?  Generic functions don't make
the combinatorics any easier than message passing -- you still have the same
number of cases to deal with.  But they make it a lot cleaner and easier to
implement a solution.  In the case of lots of different types of intersecting
objects, you write INTERSECT methods for the important cases (i.e., common,
performance limiting, etc.) and a default method which handles all the others.
Note that this default method may have to ask the two objects of interest for
help, "Give me a bit map of your perimeter".  Note the division of labor and
knowledge here.  CIRCLE doesn't have to know anything about BEZIER-CURVE to
be able to participate in an intersection test with one.

Mike Wirth
[e-mail]

PS: I suspect readers can get their fill of the message passing vs. generic
function debate in the "O.M(...) vs M(...), and is the Real World O-O?" thread
in this newsgroup.  I say "suspect" because I've stopped reading that thread --
couldn't handle the volume :-)