From: jc@ri.cadre.com (Joe Cascio)
Newsgroups: comp.object
Subject: Re: Object Relations - was: Re: Object hidd
Date: 23 Dec 92 14:45:03 GMT
Article-I.D.: fripp.1992Dec23.144503.15510
Reply-To: jc@ri.cadre.com
Organization: Cadre Technologies Inc., Providence, RI

>This is probably where these secondary relationships should be
>controlled - in the lowest common aggregator.  But sometimes, for
>efficiency reasons, I don't do that.  Instead of having the
>"transportation system" control the relationship between the (car
>with wheels) and the road, I have the wheels containing a pointer
>to the surface that they are on.  This can cause maintenance and
>debugging nightmares, but it seems to be necessary on
occasion.

A classic tradeoff:  run-time efficiency vs. maintainability.

I have had the same experience.  One technique we've borrowed from
the X window system that seems to help is to use callback function
pointers.  When the aggregator creates the constituent, two of the
arguments to the constructor are a pointer to one of the
aggregator's functions that returns the "type of road" in your
example, and a void* that is the address of the aggregator.  When
the wheel needs to know "type" of road, it calls the function
pointer, passing back the void*.  This technique allows the
constituent to remain type-decoupled from the aggregator, and
hence re-usable in the absence of the aggregator type, although
it requires the aggregator to cast the void* to it's own type.

Another solution is to pass the information as an argument only when
it is needed.

>relationship.  This causes problems if the lifetime of the
>relationship is terminated by the "transportation system" and
>no-one bothers to tell the wheel about it.
>>

Functional dependency, no?  It seems like the maintenance of
that relationship is the aggregator's responsibility.

>Things I don't like about this solution (although it's the
>only one I've got so far):
>1) the "super-aggregator" can end
>up containing virtual all of the secondary relationships in the
>application.

True.  But, better there than spread over all the constituent
objects, I think.

>2) it cuts down on re-use possibilities - no one
>else would be able to re-use my car object without creating their
>own object that can tell my car what surface its wheels are on.
>

On the contrary, I think it improves re-usability.  Better that
the re-user should be able to specify the environment, than be
forced to live with one that comes along with something it wants
to use.

At a certain level, I think you give up re-usability of the car
when you make it worry about the type of road it's on for
efficiency purposes.  If the "car-is-on-road" relationship handled
those functions (and associative objects can do that!), then the
car would remain perfectly re-usable in the absence of a road.
Also, it seems like a perfectly reasonable thing to ask of the
user of a car to be responsible for telling the car what type of
road it's on.

>tran.sys controls (owns) the relationships between them, but
>these relationships are, at least temporarily, independant of the
>tran.sys.

Again, it seems like maintenance of "transient" relationships like
this are the responsibility of the common "owner" object.  The
trans.sys could tell the truck about the driver until another
driver is assigned.

I guess what I'm trying to say with all this is that when two
objects come together in other than an "owns" relationship, it is
the responsibility of a common owner to dictate how they interact.
Otherwise, parts of the common owner begin to "leak" into the
constituents, causing them to become less re-usable in other
environments where the owner is not needed.  You may have to do
that for efficiency, but you pay the price in maintainability.

---
==============================================================
* Joe Cascio                u----wm-
* Cadre Technologies Inc.        /\
* 222 Richmond St.              0_/  "$@@#!$#@$^&"
* Providence, RI 02903 USA       \
* phone: 401-351-5950             |     . .
* FAX  : 401-455-6803            /|   .    .   . .
* email: jc@cadre.com           / | .       . .   . . .
                               ^  ^          .     .   . ....
==============================================================