Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!cs.utexas.edu!hellgate.utah.edu!uplherc!esunix!rtrosper
From: rtrosper@esunix.UUCP (Robert Trosper)
Newsgroups: comp.object
Subject: Re: is-part-of relationships
Summary: Abstract classes with navigation aids are useful
Message-ID: <1653@esunix.UUCP>
Date: 9 Nov 89 21:01:20 GMT
References: <469f709a.20b6d@apollo.HP.COM> <31417@news.Think.COM> <1941@tukki.jyu.fi>
Organization: Evans & Sutherland, Salt Lake City, Utah
Lines: 27

> In article <469f709a.20b6d@apollo.HP.COM> vinoski@apollo.HP.COM (Stephen Vinoski) writes:
> ->What's your favorite way to handle "is-part-of" relationships between objects?

I presume that one of your concerns is maintaining encapsulation while providing
access to subcomponents of the complex object.

"My favorite method" is to construct objects which know how to navigate the
database in response to user queries. Yes, this does require the controller
to know about the structure of the hierarchy, but not necessarily the
structure of each object in it.

This is not a purist approach. More pure, but many times less efficient,
is to broadcast messages to the entire database asking if they have
the requested information.

The advantage to the abstract class for navigation is that the structure
of the data can be changed without impacting the end user.

My next project is to make the database self describing, thus constructing
its own controllers, but I have sufficient work that they are paying me
for :-).

P.S. Another advantage to the controller approach is that you can peform
multiple operations or use more user-meaningful keywords and so on
without putting that stuff in all the objects.

					Robert Trosper