Re: What is wrong with OO ?

[Tansel Ersavas <tansel@rase.com>]

Robert C. Martin wrote:
> 
> The logical leap that you are making is that "procedural programming" is
> responsible for points a-e.  I'd like to see some concrete evidence to
> that effect.  The other logical leap you are implying is that OO corrects
> points a-e.  Again, I'd like to see some empirical evidence.

It is known that a vast majority of Today's systems (about 92%) are
procedure oriented systems. Do you think this is not enough? 
OO corrects this? There are no controlled studies so far, however we
plan to start one using our systems development tool late next year in
colloboration with various universities. There is also a big problem
with how we interpret, and apply OO which in most cases I observed far
less than optimal. 

> Another point is that there is massive confusion in the industry regarding
> methodology.  Should you use Booch?  OMT?  UML? How about Shlaer/Mellor?  Some
> of these methods are remarkably different from the others.  Which one yeilds
> the best benefits.  IMHO, some of them work quite well, and some are
> exceedingly dangerous.  But who do you believe?

With most dominant methodologies molding to one, the holy "Unified"
methodology with Booch, Rumbaugh and Jacobson together, I guess the
current battle is over with them having a big chunk of the market, at
least for now. I still expect some more action in methodologies corner,
especially from the RDD side. 
Which methodologies are you referring to as exceedingly dangerous ones?
 
> Thus, for the typical software manager, the costs of OO may overwhelm the
> potential benefits.  If he makes the wrong choices with respect to methodology,
> if he fails to adequately train his people in the proper use of OO, if he
> expects to immediately reduce his costs, then for him OO will be more wasteful
> and dangerous than procedural.
 
> The manager who is careful to research the methods, who checks as much
> empirical data as possible, who carefully runs trials without committing
> his whole organization, who energetically trains his people, who makes
> sure they are properly mentored during their first few projects; this manager
> may reap the benefits of OO by producing systems that are easier to change,
> easier to maintain, and easier to reuse.  This manager may be able to build
> up a stockpile of reusable software and arrange it in a framework that allows
> applications to be developed in significantly less time than before.  But those
> are very big IFs.

This is a problem I observed when I first started practicing OO. Your
observations parallel mine where switching to OO techniques were brought
at a significant cost. It does not have to be that way. 

OO in its current form is costly, because it is pushed as a useful
incremental advance over the procedural techniques. I will explain why.
<< Please do not separate any of this segment to quote,  because it is
extremely important that it is presented as a whole to keep its meaning
>>
<< Begin segment >>
We have been taught to solve problems in a certain way (i.e.
procedurally). When we are introduced to OO, we still subliminally think
in procedural terms.  The OO techniques are taught, and the development
process starts. We think, "OK, these concepts of classes and objects,
inheritence, polymorphism, and encapsulation seem to be cool" and start
applying these techniques.

If we stop there, by doing nothing but exactly using these above, all we
can get is very much like a manual and labor intensive data compression
over our procedural approach. Inheritance, besides creating a much
greater understanding about what we are dealing with, allows us to
structure our classes in nice tree forms so that we can locate
duplicated chunks easily, and promote reuse through automatic access to
procedures and data at higher levels through generalization and
specialization. Polymorphism simplifies things by allowing us to use
same familiar interface to custom tailored individual response, and
encapsulation allows us to hide implementations of these classes and
objects from others. 

All the above gives us is a different, but neat looking way of  solving
problems. We start developing systems with this approach, soon we find
out that it is difficult. Why? Because we are manually applying a "data
compression" like algorithm on top of our existing procedure orientation
approach. We can not haphazardly introduce new data and code, we have to
know about the system a lot. In the end, after a sweating experience, we
can show that our new system took longer to develop, however, it looks
somehow simpler, this much shorter and that much easier to maintain. 

If this is the approach we are taking, it is not going to be
significantly better the next time. Because we will still be using the
same compression algorithm, slightly improved after our lessons from the
first project. The results of the previous systems development effort
can offer us some reusable material, but no one will bother unless it is
made extremely simple by creating  repositories over this vast
structure. Using this technique, depending on our understanding of the
problem at hand, and ability to deliver, we can come up with ratios
similar to 1:2 to 1:5 with especially initially working much harder than
the procedural approach. 
My initial understanding of OO was something similar along these lines,
and it didn�t take me anywhere. This approach is not a major paradigm
shift and in this case all people saying that OO is an incremental
advance over procedure orientation are right if that�s all they saw so
far. 
<< End segment >>

At its simplest, data compression is an analogy that I wanted to use
because it resembles Today's OO systems development efforts. However,
there is always an overhead of data compression, it may not be feasible
for certain data, and results widely change from data to data as well as
the compression algoritm.

One of my initial failures while practicing OO was that I hadn�t
realized the most important difference of  OO to all other previous
approaches. I would like to ask this question here.

<< $1,000,000.- Question >>
What is the most important difference between the procedural paradigm
and the object oriented paradigm that makes OO a significantly different
one? 
<< End question >> 

I will answer to this question after I see peoples� responses by
referring to one of the forefathers of object orientation and one of the
great visionaries of our times.  First to answer correctly (IMO) to this
question will get a small surprise present if he or she e-mails me a
copy of the post. I am missing a lot of the postings, so there is no
guarantee that I�ll see the posted ones. If someone can actually pull
out who I am hinting about, I will have a bigger present for that
person. 

Meanwhile I would like to thank all the people sent e-mail to me. I�ll
do my best to reply them, however there are too many of them which will
take me some time to reply. I would like to thank to each and every one,
including flames, for each of them teach me something, or confront me
with questions I can come across somewhere else.

Tansel
-----------------------------------------------------------------------
RASE Inc.                                                  Clark NJ USA
Voice: (908) 396 7145                            mailto:tansel@rase.com
Fax:   (908) 382 1383                              http://www.rase.com/
----Sufficiently advanced technology is indistinguishable from magic---
-------------------------------A.C. Clarke-----------------------------