Re: What is wrong with OO ?

[matthewg@jtec.com.au (Matthew Gream)]

Hi Ahmed,

On Tue, 03 Dec 1996 17:38:37 +0000, 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.

OO is no different from many other technologies. It comes with many
promises, and it can fulfill these if used in the right situations in
the right way. It is not a panacea, which is not a new or surprising
statement.

When you consider "Object Oriented Technology", you must also consider
Domain Analysis, Architecture, Patterns and other lifecycle goodies
which are not inherently Object Oriented, but seem to be a necessary
requirement for successful OO benefits.

> Some of these claims for instance
> 1 - high reusability of objects and frameworks

This can be achieved, but it requires discipline, investment and
experience.  Discpline to work hard towards reusability, and to
maintain that reusability (though evolution). Investment in terms of
the effort involved to establish generic solutions (generic solutions
are generally [:-)] much harder than specific solutions).  Experience
to make the correct decisions when constructing re-usable items (to
have some degree of visibility).

> 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.

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.

There are also CASE tools, which make evolution and maintenance much
easier and achievable (they also keep you focused at a higher level of
logic). Having a CASE tool take care of menial details (file
organisation, includes, class definitions, method stubs, etc) and take
over some of the verification roles (use cases and scenarios) is very
important. Though, CASE tools are not inherently an OO thing.

There are probably many more items you can mention here as well.

> 3 - Easier understanding by the user and Natural transition between the analysis, design, 
> implementation because they all use tangible perceived objects.

The transition is definitely a good thing. Being able to iteratively
build software is much more predictable as well. What you've said seems
to be much easier to say that to do, from the experience I've seen
around me. Getting the right architecture and objects up front requires
experience (and therefore, knowledge). It also requires an appropriate
balance between the actual system requirements, the system domain and
other domains. This requires time and experience. 

> 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? 

I would say that it is slowely acheiving its targets and that there are
three main inter-related obstacles: time, experience and collaboration.
We need more of these to help the overall feedback loop.

> 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. 

> I know that giving a precise answer is very difficult for such a complex question, but I like to
> hear the comments of people working at the feild and who suffered from many difficulties..

> I would really appreciate any participation, response or even leading to a good reference ,
> and would be very grateful if the opinions are supported by some evidences...

You want evidence ? I need more experience :-). Please excuse my bias
towards architecture in the above as well, I think that architecture
and organisation are very important. Architecture is everywhere, from
the big to the small (in the software, in the process, in the people,
in the organisation, etc). Most of the software problems I have
encountered can be traced back to architectural issues of one form or
another.

Cheers,
Matthew.

--
Email:  Matthew.Gream@Jtec.com.au
Phone:  (02) 390-0194
Fax:    (02) 364-0055
Post:   Jtec (R&D) Pty Ltd. 
        Unit 3, 118-122 Bowden St. 
        Meadowbank NSW 2114.