NetNews Usenet Archive 1992 #31/NN_1992_31.iso/spool/comp/object/4633

Text File | 1992-12-22 | 4.6 KB | 94 lines

Newsgroups: comp.object
Path: sparky!uunet!elroy.jpl.nasa.gov!swrinde!gatech!destroyer!cs.ubc.ca!unixg.ubc.ca!kakwa.ucs.ualberta.ca!acs.ucalgary.ca!jabraham
From: [e-mail] (John Abraham)
Subject: Re: Object Relations - was: Re: Object hidden s
Sender: [e-mail] (USENET News System)
Message-ID: <[e-mail]>
Date: Tue, 22 Dec 92 17:00:44 GMT
References: <[e-mail]> <[e-mail]>
Nntp-Posting-Host: acs6.acs.ucalgary.ca
Organization: The University of Calgary, Alberta
Lines: 81

In article <[e-mail]> [e-mail] writes:
>
>I've encountered this problem, too.  It comes home to roost for me
>as life-time control.  Who "owns" or implements those secondary
>relationships?  In really nitty-gritty terms, where (in what scope)
>do you put the collections (sets. lists, whatever) that implement
>the relationship?
>
>An approach that seems to have some promise starts with structuring
>the design/implementation around the aggregation hierarchy of the
>problem.  The aggregation instances (e.g., "car" in your post), own
>(control the lifetimes) of the constituent instances.
>
>Next, the secondary relationships can be implemented in (placed in
>the scope of) the lowest common aggregator in the aggregation
>hierarchy that controls the lifetimes of the objects that the
>secondary relationship relates.

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.
Usually, however, the wheels (or the car) will query the
"transportation system" to determine what surface they are on, so
I suppose, ultimately, the relationship *is* controlled by the
lowest common aggregator, but I end up with redundant
information since the wheel also contains a copy of the
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.
>
>This may require that a top-level or "super-aggregator" class be
>introduced to provide a global scope to implement relationships
>like "rubber-meets-road" in your example.  You might have to have a
>Transportation-system class which is at a sufficiently high
>abstraction to "contain" the relationship.
>
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.
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.

>As an example, we might have an aggregation hierarchy in which a
>TransportationSystem has terminals, and trucks.  Terminals have
>employees, routes, and customers.  "Have", in this context, denotes
>aggregation.  So, for instance, the "terminal has routes"
>relationship would be implemented in the Terminal objects.  A
>secondary relationship like "truck is used by employee on route"
>has as its objects, route and employee, both owned by Terminal, and
>truck, owned by TransportationSystem.  So, the lowest common
>aggregator is TransportationSystem.
Good example.  The employee-truck-route relationships are
controlled by the tran.sys.  But surely the truck also needs to
know who's driving it, without asking the tran.sys.  So the
truck, employee and route are all owned by the tran.sys., and the
tran.sys controls (owns) the relationships between them, but
these relationships are, at least temporarily, independant of the
tran.sys.  While the driver is trucking down the road drinking
coffee his relationship with his truck is almost completely
independent of his relationship with his employer.

>
>Note that in all of this, inheritance is not a concern.  In fact,
>worrying about inheritance at an early stage of design can cause a
>lot of problems.
AGREED.  Coad-Yourdan recommend not worrying about inheritance
until final design-implementation.

--
John E. Abraham                       ***** University of Calgary
[e-mail]               **** Department of Civil Engineering
Mathematical Modelling                  *** 2500 University Dr. N.W.
Computer Simulation                      ** Calgary, AB, T2N 1N4
Transportation and Land Use Interaction   * Canada