Re: Interesting but sensitive topic to discuss (HELP: - OOP and CASE tools)

[pcg@aber.ac.uk (Piercarlo Grandi)]

>>> "vlad" == Vlastimil Adamovsky <vlad@world2u.com> writes:

vlad> pcg@aber.ac.uk (Piercarlo Grandi) wrote:

>>>>> "alovejoy" == Alan Lovejoy <alovejoy@concentric.net> writes:

alovejoy> OO programs are systems of interacting **objects**, not
alovejoy> systems of interacting **classes**.

pcg> Consider>:

pcg> class complex {
pcg> private: float rho,theta;
pcg> public: float proj_real(); float proj_imag();
pcg>         complex operator +(complex);
pcg> .... };

pcg> class rational {
pcg> private: float above,below;
pcg> public: float num(); float den();
pcg>         rational operator +(rational);
pcg> .... };

pcg> ....

pcg> So far this is not an OO program, according to your definition, for
pcg> there are no objects whatsoever in it, only classes, and there are
pcg> no ``interactions'' among classes in it either.

vlad> It is correct, your above definitions of whatever is not Object
vlad> oriented programming. You are actually defining algorithm.

The above defines two ADT implementations, for some sort of 'complex'
and 'rational' ADTs. The implementation is a class rather than a
prototype, but that does not change much; the representation is
encapsulated ('private:'), and it is implied without much detail that
all and only the procedures that need to access that representation are
listed in the class definition.

This to me seems if not an OO progam, at the very least an OO library;
In the above lines there is not much (perhaps it can be implied in the
'....' bits) of an algorithm, for there is no definition of a procedure
of function (only declarations of them).

vlad> This issue has been succesfully addressed by STL.

And by RogueWave's, and by quite a few other collections of OO
components/templates/classes/prototypes/...; to me STL and things of its
ilk do seem to be OO programs, even if they contain no interacting
objects.

Then as I remarked it is well reasonable that:

alovejoy> The architecture and design of a program is a function of what
alovejoy> **objects** it contains and how they interact.

if one rephrases it a little :-) differently; but still it seems to me
that in neither class/prototype/actor based systems programs are systems
of interacting objects...; systems of objects happen when a program is
executed, and then they interact in some meaningful way only in actor
systems, while in both class and prototype systems it is procedure
instances (os perhaps threads) that interact.

pcg> Now let's try to add some more detail:

pcg> // the above plus ...

pcg> main()
pcg> {
pcg>   complex c1, c2;
pcg>   operator >>(cin,c1); operator >>(cin,c2);
pcg>   operator <<(cout,operator +(c1,c2));
pcg>   // or more briefly: cin >> c1; cin >> c2; cout << (c1+c2);
pcg>   exit(0);
pcg> }

pcg> Is this an OO program? 

vlad> No.

pcg> To my naked eye the above is an (outline of an) OO program, but it
pcg> contains only classes ('complex' and 'rational', variables ('c1',
pcg> 'c2', 'cin', 'cout') and procedures ('main', 'operator <<',
pcg> 'operator >>' 'operator +', and 'exit').

vlad> It contains only one class 'complex', 

Well, we also have 'rational' (the second bit is an extension of the
first bit, perhaps you have missed where I say "add"), which is not used
though -- fairly common, any given OO program usually mentions only a
small fraction of the ADT implementations provided in the environment in
which it is developed.

vlad> which is in this context a mere type.

Well, in C++ classes are types; so it's a type. But what do you mean by
"mere" here?

pcg> Objects do come into existence (thanks to the execution of
pcg> constructors) only during the _execution_ of the program, and they
pcg> are passed as arguments to various procedures at execution time
pcg> too; they don't seem to be contained in the *program*, and even
pcg> when they are contained in a computation created by executing the
pcg> program they don't seem to interact, any more than the arguments to
pcg> a procedure may be said to ``interact''.

vlad> The OO design

We were actually discussing "OO programs"; but then I don't see how OO
design is much different

vlad> describes objects and their behaivor at the run-time. Behavior and
vlad> classes, types and delegees and delegators can change on demand
vlad> during running the program.  So classes are usefull to describe
vlad> behavior of a object at given time but but not at another time.

Yes, but what's the relevance of this to the question of whether "OO
programs are systems of interacting **objects**" rather than systems of
modules (either classes or prototypes or actors) that ``contain''
procedures that invoke each other?

Do OO programs by and large describe static relationships between
modules (or parts thereof like interfaces)? Or do they describe
collections of instances/clones of those modules (or their types) and
how they interact?