anne001 firstname.lastname@example.org 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
versa (“containment”). So every method of the container has acceess to
contained instance and can send messages to (aka “invoke methods on”)
If you view OO through the “hiearchy perspective” this is what
differenciates OO from procedural IMHO: procedural has only the
procedure (or function) invocations. OO does have this hiearchy of
invocations, too, but adds more, orthogonal hiearchies in different
at runtime there’s the object composition hiearchy (on instance contains
references another which in turn contains or references other instances
etc. - in fact these can form arbitrary graphs not only strict
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
One of the basic tasks of software engineering is to distribute
responsibilities properly over the code - whatever programming paradigm
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
if in a procedural system you wanted to have a function that calculates
hypotenuse you would delegate square root calculation to another
In OO environments it’s a good rule of thumb to identify classes by
at nouns. If you had to model an application that deals with cars and
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…