From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: X-Spam-Status: No, score=0.7 required=5.0 tests=BAYES_00,CTE_8BIT_MISMATCH, LOTS_OF_MONEY,REPLYTO_WITHOUT_TO_CC autolearn=no autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII X-Google-Thread: fac41,b87849933931bc93 X-Google-Attributes: gidfac41,public X-Google-Thread: 109fba,b87849933931bc93 X-Google-Attributes: gid109fba,public X-Google-Thread: 11cae8,b87849933931bc93 X-Google-Attributes: gid11cae8,public X-Google-Thread: 1108a1,b87849933931bc93 X-Google-Attributes: gid1108a1,public X-Google-Thread: 103376,b87849933931bc93 X-Google-Attributes: gid103376,public X-Google-Thread: 114809,b87849933931bc93 X-Google-Attributes: gid114809,public X-Google-Thread: f43e6,b87849933931bc93 X-Google-Attributes: gidf43e6,public From: Tansel Ersavas Subject: Re: What is wrong with OO ? Date: 1996/12/20 Message-ID: <32BB2C50.2B0B@rase.com> X-Deja-AN: 205158840 references: <32AA207E.3199@deep.net> <32B3F45C.5140@deep.net> <5956ll$16d@krusty.irvine.com> <32B758D7.61EF@deep.net> content-type: text/plain; charset=iso-8859-1 organization: RASE Inc. mime-version: 1.0 reply-to: tansel@rase.com newsgroups: comp.lang.c++,comp.lang.smalltalk,comp.lang.eiffel,comp.lang.ada,comp.lnag.java,comp.object,comp.software-eng x-mailer: Mozilla 3.0 (Win95; U) Date: 1996-12-20T00:00:00+00:00 List-Id: 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-----------------------------