Re: What is wrong with OO ?

[tbushell@fox.nstn.ns.ca (Tom Bushell)]

On 5 Dec 1996 03:56:02 GMT, ell@access2.digex.net (Ell) wrote:

>Even if "doing" good OO analysis (drawing "nice pretty little diagram" and
>*much* more) cost more time and dollars than OO coding, it pays off
>because doing good OO analysis is generally decisive to the most rapid and
>Use Case effective development of the project. 

I agree that formal high level design _should_ pay off, but there is
ample anecdotal (as provided by other contributers to this thread)
that it doesn't always.  Some might argue that this is because the
design process wasn't "good", but I wonder if this is just a symptom
of a deeper problem with formal design as it is currently practiced.
We seem to be modelling the civil engineers - draw the blueprints,
then build the bridge, and correct the blueprints "as built".  But
software is bits, not atoms, and there may be better approaches.


>And if you think about it, the only real way for what you call "design" to
>"become" the code is if a perspective larger than being mainly focused on
>physical coding *leads* physical coding.

Agreed.  I picture the design activity as creating some form of
outlines and diagrams, which would be successively refined down to the
level of running code.  But you could "back up" (zoom out?) to the
higher levels of abstraction at any point in the development (or
maintenance) process.

>This is precisely the approach of Booch/Coad/Jacobson/Rumbaugh from what I
>know about their methods.  Physical design and coding is based on/rooted
>in analysis concepts.  Physical design and coding are simply additive to
>the analysis models.

I speak only from knowledge gleaned from magazine articles, but my
understanding is that the tools are lacking to provide the outline
style views I'm looking for, with the possible exception of
Together/C++.

IMO, most of these well known methods focus on the wrong things.
There seems to be far too much emphasis on inheritance relationships,
which is not extremely useful in my experience.  I'd be much more
interested in tools that allowed me to work with dataflow and side
effects on persistant data - at various levels of abstraction.

-Tom



----------------------------------------------------------
Tom Bushell           * Custom Software Development
Telekinetics            * Process Improvement Consulting
2653 Highway 202          * Technical Writing
RR#1, Elmsdale, NS
B0N 1M0
(902)632-2772         Email: tbushell@fox.nstn.ns.ca
----------------------------------------------------------