Re: What is wrong with OO ?

[rmartin@oma.com (Robert C. Martin)]

In article <32A4659D.347A@shef.ac.uk>, Ahmed <ACQ95AA@shef.ac.uk> wrote:

> Object Oriented Technology came with quite promising claims that if
achieved can benefit the software 
> development companies and organisations millions of pounds.

Those claims were not made by the engineers and researchers who "invented"
OO.  They were made by marketeers who found a new way to differentiate 
products, and by engineers who had shut off their ability to employ
critical thinking.

> 
> Some of these claims for instance
> 1 - high reusability of objects and frameworks
> 2 - Resilience to change, i.e. low software maintenance and evolution cost
> 3 - Easier understanding by the user and Natural transition between the
analysis, design, 
> implementation because they all use tangible perceived objects.
> 
> However the reality is not so bright as claimed..if so, then nobody
today thought to  develop a
> software on the traditional structural methods...
> 
> My question is what is wrong with OO ? why it did not achieved its
targets yet.?
> What are the main obstacles? 

The claims were too grandiose.  Software is still software; and it is still
hard.  There are still bugs, still ambiguous specifications, still volatile
specifications, still improperly trained engineers, still engineers who 
shouldn't be engineers, still managers who don't understand the technology
they are trying to manage, still arbitrary completion dates, etc, etc, etc.

In any case, you shouldn't be surprised when highly publicized claims are
not achieved.  Generally those claims are just part of the overall hype 
associated with any new idea.

The truth is:  (If I may be so bold as to claim to know the truth ;)

  1-  OO, when properly employed, does enhance the reusability of
      software.  But it does so at the cost of complexity and design
      time.  Reusable code is more complex and takes longer to design
      and implement.  Futhermore, it often takes two or more tries
      to create somthing that is even marginally reusable.

  2-  OO, when properly employed, does enhance the software's resilience
      to change.  But it does so at the cost of complexity and design
      time.  This trade off is almost always a win, but it is hard to
      swallow sometimes.  

  3-  OO does not necessarily make anything easier to understand.
      There is no magical mapping between the software concepts and
      every human's map of the real world.  Every person is different.
      What one person percieves to be a simple and elegant design, another
      will percieve as convoluted and opaque.

  4-  If a team has been able, by applying point 1 above, to create 
      a repository of reusable items, then development times can begin
      to shrink significantly due to reuse.

  5-  If a team has been able, by applying point 2 above, to create
      software that is resilient to change, then maintenance of that
      software will be much simpler and much less error prone.

In short.  Nothing has gone wrong with OO.  It is a technology, and it
delivers everything it was designed to deliver, and perhaps a bit more.
That it doesn't live up to the naive claims made by naive or insincere people
is unfortunate, but not unexpected.

> 
> Is the problem with the immature OO methodologies ( OO analysis and
design in specific ) ?

No, these techniques have been a major contribution to software engineering,
and have gone a long way towards improving the way we build software.

> or is it the deficiency in the development  tools used like C++ or Smalltalk ?

No, the tools are more or less adequate for the job.  IMHO, someone
who blames a language for a failure should be looking a bit closer to 
home for the cause.

> or is it the steep difference in thinking between the traditional and OO
schools ?

I don't think it's the steepness of the difference, although the difference
can be very steep.  Instead I think that it is the disagreement by OO
authorities on the endpoint of that learning curve.  

For example, some folks will tell you that the secret of OO is think of the
world in terms of objects.  Others will tell you that it is to think
of the structure of the software in terms of polymorphic interfaces.  Still
others will tell you that it is to decouple the domains of the problem
by describing them using macros that can be statically bound at compile time.

Which is right?  Which is real?  There is a *lot* of confusion out there.
That some folks might not be experiencing any of the benefits of OO does 
not surprise me.  (BTW, my own choice is one about structuring the software
in terms of polymorphic interfaces)

-- 
Robert C. Martin    | Design Consulting   | Training courses offered:
Object Mentor       | rmartin@oma.com     |   Object Oriented Design
14619 N Somerset Cr | Tel: (847) 918-1004 |   C++
Green Oaks IL 60048 | Fax: (847) 918-1023 | http://www.oma.com  

"One of the great commandments of science is:
    'Mistrust arguments from authority.'" -- Carl Sagan