Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!usc!apple!motcsd!lance
From: lance@motcsd.csd.mot.com (lance.norskog)
Newsgroups: comp.object
Subject: Objects and Interactions: Separate Definitions
Message-ID: <3999@motcsd.csd.mot.com>
Date: 21 May 91 01:52:20 GMT
Distribution: comp
Organization: Motorola CSD, Cupertino CA
Lines: 66

preece@urbana.mcd.mot.com (Scott E. Preece) writes:

>In article <1991May3.212005.29453@visix.com> amanda@visix.com (Amanda Walker) writes:
>|
>|   ...  A trivial example of this idea is that a heapsort
>|   should operate on any set of objects for which I can provide
>|   comparison and exchange operations.
>---
>OK, let me expose my ignorance[1].  I'd like to see how object-oriented
>design works.  Would you care to sketch the design for this?  My naive
>model would be that a heap is an object and that it has add and remove
>methods to take objects of unspecified type and stick them into the heap
>in the right place.  So where do the comparison and exchange procedures
>go?  I see two alternatives[2]: (1) the heap object has compare and
>exchange methods that "know about" all of the types, figure out what's
>involved, and operate on the member objects or (2) the objects have
>methods that report their "comparable value" and size in canonical forms
>that a generic routine in the heap object can operate on.  Neither of
>these makes me awfully happy.  

Standard practice, like Smalltalk, follows (2).  C++ seems to do (1)
for handling type conversions.

Class definitions seem to have two jobs: a) defining the "Buddha Nature"
of a class, and b) defining the interactions of that class and
some other class.  B) generally involves describing a particular
interaction in two different places: one in the class, and another
in some other class that interacts with the first class.  I'm 
happy putting A) in a class definition, but B) splits the interaction
into 2 different places, increasing "code entropy".

An alternative is to have a separate
set of declarations which define interactions between objects.  These
interaction definitions are where you code up classic algorithms.

Let's say we have objects X and Y, and that in Smalltalk X would use
Y in some way, by sending it messages and interpreting the responses.
With interaction definitions, X would say "Start interaction Z
with Y".  An instance of interaction definition Z is created,
and it sends any number of messages to X and Y, interpreting the
responses.  Objects don't send messages to other objects.

Separating objects and their interactions shears class definitions 
of descriptions of their dealings with other specific objects, and 
leaves them only with a small, simple set of messages and responses.
My theory is that this will encourage defining small, simple,
reusable objects.  

An interaction between classes, including abstract superclasses,
is inherited by all subclasses.  This solves my problem in
my 3d software in which I have to define a new class PaintedObject
with one operation Paint in order to impress a 2D or 3D texture
onto any drawable object.  It struct me as overkill to create
a new class with one little operation, and interfered with my
scoping system.

Now, of course, we have the problem of making mutant copies 
of interactions easily.  I have no clean solutions for this.

I've heard the term entity-relationship (ER) bandied about, and seen
it in books, but haven't tracked down a full comprehension.
It may be that I'm crossing ER with objects.

Comments?

Lance Norskog