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 (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
···
anne001 <anne@wjh.harvard.edu> wrote:
