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

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

>>> "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.

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? It's hard for me to see any objects in it either
for I can only see variables (memory objects, a different concept) and
they don't interact with each other in any sort of interesting meaning
of the word.

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').

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''.

alovejoy> What classes these objects may or may not be instances of is a
alovejoy> separate issue--a fact which becomes obvious in a Self
alovejoy> program, for example.  What matters is the **interface**
alovejoy> supported by each object,

alovejoy> and the **role** each object plays in the program.  Note that
alovejoy> two objects may support the same interface, but be instances
alovejoy> of different classes and/or play different roles.

What is a role that an object may play? It is usually easy to see
interfaces in OO programs; for example in the above program it is easy
to discern which interfaces the 'complex' and 'rational' classes have
got; but what roles do objects play in the above program?

I do realize that according to your definitions the above program is not
an OO program (there are no objects and no interaction among them); then
perhaps you could provide an example of an OO program, in which
according to your definition there are objects, they ``interact'', they
have interfaces, and they play roles. For the sake of appealing to a
wider audience, it would be important that the example be written in
something resembling C++.