anne001 <anne / wjh.harvard.edu> wrote:
> Yes, I am aware of the structure.
> object.message
>
> In discussions of OOP I read, the difference is made between
> procedural, which starts with data, and flows from action to action to
> an end point in a structure organized by time, and OOP, portrayed as
> objects linked together by actions in timeless fashion.
>
> I think what I am discovering, is that for most of its communication,
> OOP relies on a hierarchy all the same, but a hierarchy of objects. If
> 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 Britt 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 
http://ootips.org/uml-hasa.html ).

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