Re: What is wrong with OO ?

[piercarl@sabi.demon.co.uk (Piercarlo Grandi)]

>>> "tbushell" == Tom Bushell <tbushell@fox.nstn.ns.ca> writes:

tbushell> On 05 Dec 1996 22:30:40 +0000, pcg@aber.ac.uk (Piercarlo
tbushell> Grandi) wrote:

pcg> *If* analisys and design efforts were conducted in resonance with
pcg> each other and implementation, then spending more effort on those
pcg> than coding would be all fine and actually rather useful,

tbushell> I agree that the effort is useful.  But my gut feeling is that
tbushell> with better (and apparently undiscovered, as yet) processes
tbushell> and tools, the high level design activity should be about 10%
tbushell> of the total project, not around 50%.

Perhaps the reverse: if the tools were really advanced, perhaps
including a program generator (and despite claims to the contrary no
such thing has been yet produced), then high level design activity would
be almost all the project. As things stand, human work on the ``lower''
levels of a project is indispensable, and communication problems between
the humans doing the various levels of abstraction, if the total effort
is divided in groups corresponding to such levels of abstraction, can
cause embarassing problems, as Robert Martin has always observed.

tbushell> Contrast this with doing the blueprints for a bridge - the
tbushell> design effort is orders of magnitude cheaper than the
tbushell> construction.  (Or so I believe - a civil engineer might
tbushell> correct me on this).

pcg> It is usually _cheaper_, but on the other hand it might take
pcg> _longer_.

tbushell> I assume this is because the design is the work of a much
tbushell> smaller team, whose only physical output is computer models or
tbushell> paper.

Not quite, because while _building_ the bridge is an almost-mechanical
project, designing it requires a lot of hard thought, and consultation
with users, and in particular lots of iterations and refinements.

However designing a bridge and building it are not a good analogy for
analysis/design and vs. coding; more like an analogy for all three of
analisys/design/coding vs. execution.

Naturally building a bridge from blueprints is not quite as mechanical
as executing a program, for bridges are built by human teams using quite
but not-so-precise blueprints. Still it has the characteristics of
execution: an abstraction is turned into an instance (and potentially
many instances, in the case of things other than bridges of course).

tbushell> This is my point - other engineering disciplines appear to
tbushell> routinely put much less total effort into design, with much
tbushell> greater success.  I guess this is just the positive result of
tbushell> greater maturity as a discipline.

Well, my impression is exactly the opposite: that the design of material
entities like a new car or an airplane model requires immense amount of
money and time, as compared to almost any software project, and as many
iterations, and as much debugging, if not more, and then there are as
many *design* bugs (as opposed to manufacturing defects) in the finished
products. The saving grace is that cars and other physical systems like
a building (but surely not airplanes) are usually, but not often simpler
than doing software.

Even in *cost* designing a new car or airplane can be a significantly
large part of the cost of each instance of the design. I would even
argue that the percentage of the sale price of instances that repays the
development cost can be significantly higher for cars or airplanes than
for software.

  Then while a large part of the sale price covers instantion costs for
  cars and airplanes, the instantiation costs of software are very
  small, and most of the sale price covers marketing expenses and
  profit; in this software is more like soft drinks and perfumes,
  physical products sold on their intangible value, than cars or
  airplanes.

tbushell> Also, the OO design models I've studied don't seem to be very
tbushell> good maps of actual real world systems - there seems to be a
tbushell> big gap between high level architecture and running code.  I

This is a good reason why architectures as maps of real world system are
not such a good idea.

tbushell> believe there should be a fairly smooth continuim from high
tbushell> level to low level of detail.

piercarl> Why?

tbushell> Why not? ;-) (Don't know what you're asking here...)

I am asking for any argument to support the statements you make. You
support your observations with reference to "my gut feeling", "Or so I
believe", and "I believe there should be".

This is all fine, but then you should provide some argument as to why
your gut feelings or beliefs are; for they are about some points where
plausibility can work either way, and it's hard to trust one's own
instincts in such matter.

pcg> But OO is in large part about this: the ``high level''
pcg> modules/classes/prototypes are supposed to capture the essence of
pcg> the design. Pointing some sort of OO program browser to a program
pcg> source and removing from the picture the lower levels of
pcg> abstraction *ought* to reveal the design. This *ought* to be the
pcg> case with structured programming methods in general, and with OO in
pcg> particular it should be even more pleasant because of the
pcg> disciplined modularization of the program it entails.

tbushell> Absolutely!  But why doesn't it work out that way?

Because achieving this requires hard thinking. This is typically beyond
the state of the art.

Or perhaps because the rather vague statements by those who believe in
``silver bullets'', in particular those with ``real world modeling'' on
them, mean that many people don't focus hard enough on the structure of
programs _as such_; there is evidence as to what is a good structure for
a model of the ``real world'', and then that this would also be a good
structure for a program. There is instead some sparse but good evidence
about what is a better structure for a program as such.