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

[vlad@world2u.com (Vlastimil Adamovsky)]

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

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

>alovejoy> Objects are objects, not classes.

>Ok, even if there are some famous authors that don't seem to agree.

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

>Consider:

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

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

>  ....

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

It is correct, your above definitions of whatever is not Object oriented
programming. You are actually defining algorithm. This issue has been
succesfully addressed by STL.

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

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

>  // the above plus ...

>  main()
>  {
>    complex c1, c2;

>    operator >>(cin,c1); operator >>(cin,c2);
>    operator <<(cout,operator +(c1,c2));

>    // or more briefly: cin >> c1; cin >> c2; cout << (c1+c2);

>    exit(0);
>  }

>Is this an OO program? 

No.

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

It contains only one class 'complex', which is in this context a mere type.

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

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



I

 Vlastimil Adamovsky
 ** C++ and Smalltalk consultant **
 * http://www.stepweb.com *