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

[jhd@herold.franken.de (Joachim Durchholz)]

alovejoy@concentric.net wrote 06.11.96:

> Objects are objects, not classes.

Of course :)

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

I think this is a bit misleading.
OO program texts are definitely systems of classes (or, rather, textual  
representations of classes). We don't specify a single objects when  
writing code for a class; instead, we specify the behaviour of a set of  
objects, of which there may be none, one, or an unlimited number present  
at run-time.

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

Well, now I have to disagree. An OO program consists of classes, which are  
descriptions of the behaviour of object sets. I.e. it is object behaviour  
that we describe, not objects themselves (which are a bit irrelevant  
anyway, we want the computer to *behave*, not to *be*).

> Class inheritance is an abstraction mechanism for code sharing.

It is much more. It is a mechanism for specifying similarities, and in  
this respect goes far beyond mere code sharing.
I can have exactly the same amount of code sharing with subroutines (that  
take routines as parameters in cases where I need dynamic dispatch). This  
is available in C, but nobody would regard C equivalent to an OO language!

> It has
> nothing much to do with architecture or design of a program.  Proof: any
> program using class inheritance can easily be converted into a completely
> equivalent program where all the leaf classes are root classes: one simply
> duplicates all the inherited methods in each leaf class.

On the same basis, I could declare C to be equivalent to assembler. Proof:  
it is always possible to mechanically produce an equivalent assembler  
program. (I won't do this :)

The mere possibility to reproduce a program in a different way just proves  
Turing equivalence, which we aren't too interested in when discussing  
software engineering issues. The real issues are readability,  
maintainability, and reusability of the code, by a human programmer, and  
representation can have a tremendous impact on that.

Regards,
-Joachim

--
Looking for a new job. Resume available on request. WWW version of resume
available under http://www.franken.de/users/herold/jhd/resume/index.html