Tod wrote:

/ ...

> Someone yesterday said you would create a superclass that both of these
> objects would share and this superclass would handle communication
> between the objects. I can see how that would work. But is that the
> only way? Is there no way for ruby objects to communicate directly with
> one another?

No, in fact, there are any number of ways to do this. The question you
should be asking is which of the available methods meets your requirements
most efficiently.

Obviously, using your example of a student registration system, the
student's identity is the key to the relationship between objects.
Therefore a parent class containing everything that is known about the
student should deal with various aspects of the student -- registration,
arranging for classes, health care, grades, whatever.

In the process of applying for a particular class for example, the object
responsible for requesting a particular course would pass this request to a
parent class that coordinates all activities for that particular student,
and that class on turn would communicate with a class responsible for
assigning courses university-wide.

The student's data is obviously self-contained, no peer-to-peer transactions
required. But the communication between the student's data and that
belonging to the university would be by way of another hierarchy of
classes, one in which the university's master record-keeping system would
be the parent of each student record.

My point is true peer-to-peer transactions without a parent class to
coordinate the activities are rare, and should be avoided if possible. Many
data relations are naturally hierarchical, and this architecture is also
easy for the maintainer to understand and modify.

-- 
Paul Lutus
http://www.arachnoid.com