Re: What is wrong with OO ?

[harry@matilda.alt.net.au (Harry Protoolis)]

On Thu, 05 Dec 1996 03:06:57 GMT, Tom Bushell <tbushell@fox.nstn.ns.ca> wrote:
>On Wed, 04 Dec 1996 08:45:22 -0600, rmartin@oma.com (Robert C. Martin)
>wrote:
>
>>harry@matilda.alt.net.au (Harry Protoolis) wrote:
>>
>>> The traditional techniques all suffered from a number of significant
>>> flaws. Perhaps the most damaging one was what I (rather unkindly) think
>>> of as 'The glorification of idiots' phenomenon. What I mean by this is
>>> that projects were typically infested by a group of people who never
>>> wrote any software, but spent most of the budget drawing diagrams that
>>> the implementors never used.
>>
>>Much to my dismay, there are some OO methods that are promoting 
>>the same scheme.  The "analyst" draw nice pretty little diagrams, and
>>even run them through simulators to "prove" that they work.  These
>>diagrams are then run through a program that generates code.  Programmers
>>who maintain that code generator have to make sure that the "right" code
>>is generated.  They have to make the program work.
>
>It is my growing opinion that this is a fundamental problem with all
>"formal" design methods, not just OO design.  The effort involved in
>doing the design is as great or greater than doing the construction
>(coding).  Contrast this with doing the blueprints for a bridge - the
>design effort is orders of magnitude cheaper than the construction.
>(Or so I believe - a civil engineer might correct me on this).  Also,
>the OO design models I've studied don't seem to be very good maps of
>actual real world systems - there seems to be a big gap between high
>level architecture and running code.  I believe there should be a
>fairly smooth continuim from high level to low level of detail.

IMHO, the trick with OO design is to do it *informally* most of the
time. What I mean by this is that you sketch out high level architecture
and analysis results as high level class diagrams and then give them to
the 'implementors' to design and code.

The implementation team then does design as a series of informal
gatherings around a white board drawing state diagrams, detailed class
diagrams, object diagrams etc. You then photocopy and file the
whiteboard drawings and let the same group of people code from the
hand drawn design.

I then quite often reverse-engineer the resulting code and call *that*
the formal system design.

I do some formal tracking of this design process, but the golden rule is
that nothing should get in the way of the creative process. The failure
of *all* attempts at formal design is this mistaken belief that anything
short of coding can replace coding ... 

>I'm starting to believe that design and code don't make sense as
>separate entities - the design should _become_ the code - the design
>documents for an implemented system are used as the foundation of the
>code, and then regenerated from the code.  Major benefits would be
>that design work would not be discarded because it was too difficult
>to bring it up to date with reality.  Therefore, the design should
>never get out of synch.  This a similar idea to reverse engineering,
>but not identical.

My point is that the *design* and the *code* come into existance
together. To talk about the design becoming the code implies that it
exists before the code in some sense.

>If anyone has knows of tools that would facilitate this approach, I'd
>certainly be interested.  I've done some very simple prototypes, and
>hope to work on the idea in future (when I have more time - Hah!).

I think that a facinating tool would be a language sensitive drawing
tool in which you could switch your view between diagrams and code and
write 'code' in either view.

H
-
Harry Protoolis                              alt.computer pty ltd                 
harry@alt.net.au                             software development consultants