Re: What is wrong with OO ?

[Tim Ottinger <tottinge@dave-world.net>]

Matthew Gream wrote (And all in all, a thoughtful posting):
[in response to question:]
> > 2 - Resilience to change, i.e. low software maintenance and evolution cost
> 
> How flexible is the software? This has a lot to do with architecture:
> "if you don't get the architecture right up front, you may as well pack
> up and go home" [quote made by a fellow engineer]. The architecture in
> many ways predicts what will happen to the software over its
> lifecycle.  If you don't get this right, you will need to change the
> architecture: this is usually not a trivial task. This is not exclusively
> an OO issue though.

By the way, while this is "essentially" right, there are plenty of cases
where people did not build the correct architecture the first time out.
In fact, many of us will tell you that it's nigh impossible to build it
right the first time out if the software project is interesting enough.

The iterative incremental model ain't perfect, but using short cycles
and daring to revisit can cover an awful lot of design sins. If you
commit to an architecture, then you're probably stuck. 

I propose the motto "design by distrust!".  If the work is suitably 
isolated from the physical and business requirements, then you can 
reliably insulate yourself from those things you don't believe will
be invariant, even if you don't know which direction they'll go in.

Of course, this *is* your next point, but I wanted to stress that 
it's not a top-down thing, and the process is not completely 
unforgiving.  Otherwise, we'd be better off outside of OO for large
projects.

The architecture thing, even the business model, can be essentially
right and correctably wrong, and sometimes it's a close to perfection
as you'll get.  Especially early on in a project.

> OO includes inheritence. This promotes generalisation -- factoring out
> commonalities -- which reduces dependencies. Reduction in dependencies
> makes maintenance and evolution more predictable and cheaper. It is
> perhaps predictability that is more important than anything, better to
> correctly assess that all the costs are high up front, before starting,
> rather than finding out later.

Design by distrust! Estimate by distrust!

> > Is the problem with the immature OO methodologies ( OO analysis and design in specific ) ?
> > or is it the deficiency in the development  tools used like C++ or Smalltalk ?
> > or is it the steep difference in thinking between the traditional and OO schools ?
> > or is it  related with the difficulty of object classification ?
> > or is it  because of vast legacy systems done using the traditional methods ?
> > or is a combination of many other factors...?
> 
> All of these would seem to be problems from my, limited, experience. The
> thinking "mindset" is perhaps one of the most important.

To begin with, I don't accept the idea that there is a "problem".
I'll talk about that in a second.

Secondly, I think that the difference in thinking between OO and 
structured is a matter of breaking mental habits, not the deep and
nearly incrossible chasm people make it out to be.  We have people
who jump from COBOL to C++ and OO in one great leap.  We have a 
number of people who came from procedural 4GLs to OO.  It happens
very frequently, maybe every week or every day all over the world
with thousands and thousands of people.

A lot of the "problem" is with organizations.  If they've been
successful
to any degree with other methods (including brute force) then they are 
unlikely to "mess with the formula" by going into OO.  A lot of people
still use Fortranm, COBOL, RPG, etc., successfully - untouched by the
Client/Server revolution, CASE, even RDBMS.  No person or company is 
obliged to stay "technically current", and so many will not.  And they
might do fine at it.

The fact of the matter is that OO is a change in management and project
planning as much as anything else, and a lot of managers aren't too
keen on having their world ripped out from under them.  That's just
an education thing.  It'll come in time, but the focus on managing 
OO is fairly recent in the scheme of things.

There's an underlying myth of the question which was originally asked.
"If method A is good, then why does anybody do anything else", or 
"If some people don't use A, then it must not be very good". 

If I asked "If software is a good career, then why do some people
still raise crops?" you might laugh. Software is not for every-
body.  For that matter, you know that managers and financial people
make more money than programmers, so whats wrong with you that you
don't go into management instead?  Well, maybe programming is fine
for you.  Maybe that money benefit isn't all that important to you.
Does that mean that managers *don't* make more money?

Likewise OO. It's not a winner-take-all battle with the rest 
of the DP world.  It doesn't have to be popular, and it doesn't 
have to be used exclusively by all software companies in order 
to work.

It's just a set of mental tools you can use if you want the
benefits it can provide.  

Some people are gung-ho, some are skeptical, some don't care.  And 
they have that right.

-- 
Tim
******************************************************************** 
 In some sense, all of life is design.  The way we pick our friends, 
 the way we plant a garden, and the way we choose software is all 
 design. Sometimes we do things by habit, other times by carefully 
 weighing the pros and cons, and sometimes we make experiments.  
                                            -- Ralph Johnson --