Re: What is wrong with OO ?

[smize@news.imagin.net (Samuel Mize)]

In article <32B3DD77.2F17@deep.net>, Tansel Ersavas  <tansel@deep.net> wrote:
>drush@zakalwe.raleigh.ibm.com wrote:
>
>> Regarding Objects & "real-world" modeling: I have also seen this as primarily
...
>OO provides us with a set of tools to abstract things in the real world,
>imagined worlds, or anything. We should remember that there is a
>discipline which their entire aim is to model the real world as close as
>possible, and this discipline is simulation, not OO. There you need your
>system to match the current reality as close as possible. OO can be used
>for that, better then most other techniques available Today, and in fact
>guess why Simula, the ancestor of most object oriented languages was
>developed. 

This discussion has been pushing one of my hot buttons, and you just
crystallized my response.  Thanks!

One of my problems with many OO "gurus" is the frequent mantra that the
OO products should match the real world's objects, right down to the code.
They claim that this will make the code easier to understand, and that
current processors are so fast that any moderate inefficiency is invisible.

Both of these claims are patently false.

I work in simulation.  A critical issue in simulation is "level of
fidelity" -- how closely do you want to simulate the real-world object?
More fidelity implies greater cost.

I've seen subsystems that could have been coded simply, that became
baroque and incomprehensible because they tried to hew to the "real
world model" approach instead of computing the needed results.

I've seen a subsystem burning multiples of its execution-time budget
because it was coded to map to the real world.  Specifically, we
were using a hydraulic model to generate realistic flow dynamics, when
a binary flow/no-flow model would have been adequate.  This wasn't
directly an OO problem -- we should have timed large models much
earlier than we did -- but the OO paradigm, as promoted in that project,
helped obscure the problem until late in development.

I have often found object-oriented analysis, design and coding methods
to be extremely helpful.  I look forward to being able to use Ada95's
OO features in a significant way (right now I'm doing maintenance and
upgrade work).

But I have heard too often the claim that an OO design should just be
a deeper iteration of the analysis, and I haven't found that to be the
case.  Even after the project is done, the analysis and design should
often NOT match -- although the mismatches should be understood,
explained, and documented.

The analysis should match the real world -- it should show what the
real world will be like with your system in it.  The design should be a
structure that will implement (part of) the analysis model, and it might
do so differently from a current real-world system, or from an external
view of its actions.

Figuring out the DIFFERENCES that should exist between the analysis and
design models is the essence of high-level OO design.

>> The "real-world" is the system that you're replacing. To inflict that structure
>> on the system you're designing can be a *BIG* mistake.
>
>Depends, it may be, or it may not be.

Yep.  It may not be, but it "can be a *BIG* mistake."  As you said,

>However, in the man made world we call "real", there are a lot of things
>you don't want to incorporate into your design.

I think we three basically agree.  Thanks for sparking me off.

Samuel Mize