anne001 [email protected] wrote:
object A and object B need to communicate, they can as long as they
are embedded in object C which can call on A and on B as needed.
Something like that.
Not only: there’s no need for C to be present. A can reference B or
vice
versa (“containment”). So every method of the container has acceess to
the
contained instance and can send messages to (aka “invoke methods on”)
that
instance.
If you view OO through the “hiearchy perspective” this is what
differenciates OO from procedural IMHO: procedural has only the
hierarchy of
procedure (or function) invocations. OO does have this hiearchy of
method
invocations, too, but adds more, orthogonal hiearchies in different
areas:
at runtime there’s the object composition hiearchy (on instance contains
or
references another which in turn contains or references other instances
etc. - in fact these can form arbitrary graphs not only strict
hiearchies).
Then there’s the hierarchy of type relations called “class hiearchy”.
That seems to be what OOP demystified is explaining in its example on
collaboration in chapter 9. Because Keogth called the super class,
linkCourseStudent, I did not realize that it was creating a class in a
hierarchy which could create an instance of objects of class Course
and of class Student, and call each instance method, giving “the
appearance” of communication.
As James B. showed me, it is possible for A and B to communicate
without being embeded in a common hierarchical object, but it is much
less commonly done.
IMHO the most common situation is actually where one instance references
another instance (in UML speak “aggregation” or “composition”, see also
(ootips) Association, Aggregation and Composition ).
One of the basic tasks of software engineering is to distribute
responsibilities properly over the code - whatever programming paradigm
(OO,
procedural, functional) is used. For procedural languages this means to
identify the sub task that is delegated to another function / procedure
which can be invoked by several other functions / procedures. For
example,
if in a procedural system you wanted to have a function that calculates
the
hypotenuse you would delegate square root calculation to another
function.
In OO environments it’s a good rule of thumb to identify classes by
looking
at nouns. If you had to model an application that deals with cars and
their
pieces you’d probably choose “car”, “wheel”, “engine”, “lorry”, “bus” as
classes, where some of the typically belong into an inheritance hiearchy
(“car” probably as base class, “lorry”, “bus”) and others usually form a
containment hiearchy (a “car” has_an “engine” etc.). If you managed to
identify classes then you often also know their methods (“start” for
“engine” etc.). Of course it’s not always that simple…
HTH
Kind regards
robert
