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=-1.9 required=5.0 tests=BAYES_00 autolearn=ham autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 103376,73036d0217be91e2 X-Google-Attributes: gid103376,public From: mfeldman@seas.gwu.edu (Michael Feldman) Subject: Re: Inheritance versus Generics Date: 1997/04/26 Message-ID: <5juemo$bca@felix.seas.gwu.edu> X-Deja-AN: 237628003 References: <33601924.774@flash.net> Organization: George Washington University Newsgroups: comp.lang.ada Date: 1997-04-26T00:00:00+00:00 List-Id: A Few "Sound Bites" on Object-Oriented Programming Michael B. Feldman The George Washington University ------------------------------------------------------------- "My guess is that object-oriented programming will be in the 1980s what structured programming was in the 1970s. Everyone will be in favor of it. Every manufacturer will promote his products as supporting it. Every manager will pay lip service to it. Every programmer will practice it (differently). And no one will know just what it is." Tim Rentsch 1982 (one of the original Xerox Smalltalkers) (as quoted by Booch) ------------------------------------------------------------- "Everything is an object these days; if it doesn't have o-b-j-e-c-t in the name, it won't sell...OOT is so radically different that we must break and reset programmers' coding hands before they can write object-oriented instead of procedural programs. This is much worse than the structured programming hoopla of the 1970s...If we convert one Cobol programmer per minute to Smalltalk, we should have a revolution by the time Capt. Kirk and the USS Enterprise return from Vulca on impulse power." Ted Lewis, "The Dark Side of Objects", IEEE Computer, Dec. 1994. ------------------------------------------------------------- Composition vs. Classification (paraphrasing here) Objects gather both data structures and program structures. Classification: objects are organized in a hierarchy of classes. General classes contain features common to many subclasses, and specalized subclasses implement only behaviors that are common to a subset of the parent class's objects. Composition: objects are made of different parts, and that the same parts can be used to make a variety of higher-level objects. Each object is designed as an assembly of lower-level components. There is no need to know how a component is made in order to use it. A set of parts that form an object constitutes an abstraction layer. This is what is generally used in engineering, and has been especially successful in the electronic industry. (quoting directly here) "Why do so many people believe that classification is the only 'true' object orientation? Perhaps because OOL designers place a heavy emphasis on inheritance, which is clearly necessary only to classification." J-P Rosen, "What Orientation Should Ada Objects Take?" Communications of the ACM, Nov. 1992 ------------------------------------------------------------- "There is a very real tension between inheritance and encapsulation. To a large degree, the use of inheritance exposes some of the secrets of an inherited class. Practically, this means that to understand the meaning of a particular class, you must often study all of its superclasses, sometimes including their inside views." Grady Booch, Object-Oriented Design with Applications, Benjamin Cummings, 1991. ------------------------------------------------------------- "OOT has a nasty 'fragile base class problem,' which means that once a program is designed and implemented as a class hierarchy, it is maximally coupled. Changing one interface specification brings the whole house of cards tumbling down. We were warned against this in 1975 (minimize coupling, maximize cohesion). Coupling is a serious maintenance nightmare that bit Mentor Graphics (Falcon Framework) in the bottom line. How many other software companies are headed for OOT malaise?" Lewis, op. cit. ------------------------------------------------------------- "[I]nheritance is often used not for classification, but just to grab pieces of code. . .makes a class PARROT inherit from the class HUMAN-BEING because it needs the property CAN-SPEAK. This kind of misuse of the inheritance mechanism, especially when multiple inheritance is available, is extremely tempting to the programmer who just wants to 'reuse' existing code, while actually introducing a terrible mess in the dependencies between objects. ... "In the slums, people build houses by reusing old items such as pieces of wood and tires, and adjusting them to their needs. This kind of reuse is often extremely clever, and if you absoutely need a shelter rapidly, it is certainly an efficient method. But will the house withstand a storm? This is certainly not industrial reuse, which is building houses from well-engineered, standard prefabricated components. ... "Ada object orientation will still not just follow classification, because classification does not answer properly a number of requirements for Ada applications. In general, classification will favor ease of design and rapidly varying specifications such as those encountered when prototyping software, while composition will better match the needs of secure, long-lasting systems, requiring various implementations of the same abstract behavior." J-P Rosen, op. cit. ------------------------------------------------------------- "-- Most past progress in software productivity has come from eliminating non-inherent difficulties such as awkward machine languages and slow batch turnaround. "-- There are not a lot more of these easy pickings. "-- Radical progress is going to have to come from attacking the essential difficulties of fashioning complex conceptual constructs. "The most obvious way to do this recognizes that programs are made up of conceptual chunks much larger than the individual high-level language statement -- subroutines, or modules, or classes. If we can limit design and building so that we only do the putting together and parameterization of such chunks from prebuilt collections, we have radically raised the conceptual level, and eliminated the vast amounts of work and the copious opportunities for error that dwell at the individual statement level. "Parnas's information-hiding definition of modules is the first published step in that crucially important research program, and it is an intellectlual ancestor of object-oriented programming He defined a module as a software entity with its own data model and its own set of operations. Its data can only be accessed via one of its proper operations. "The second step was a contribution of several thinkers: the upgrading of the Parnas module into an abstract data type, from which many objects could be derived. The abstract data type provides a uniform way of thinking about and specifying module interfaces, and an access discipline that is easy to enforce. "The third step, object-oriented programming, introduces the powerful concept of inheritance, whereby classes (data types) take as defaults specified attributes of their ancestors in the class hierarchy. Most of what we hope to gain from object-oriented programming derives in fact from the first step, module encapsulation, plus the idea of prebuilt libraries or modules or classes that are designed and tested for reuse." Fred Brooks, "The Mythical Man-Month after 20 Years", IEEE Computer, Sept. 1995. ------------------------------------------------------------- "Unfortunately for the information technology industry, many object technology (OT) gurus are still touting the role of inheritance and subclassing in building reusable business objects. One well-designed parent, they say, such as a Customer object, allows developers to effortlessly spawn dozens of reusable kin. These theories of inheritance sound pretty good-until you try applying them to building an industrial -strength application . "We have spent more than 150 work-years tackling this issue and many others related to building commercial object-oriented systems. The verdict on inheritance and reuse? Uncontrolled and unplanned subclassing results in code as fragile and hard to maintain as the COBOL programs we're replacing. Moreover, subclassing often is counterproductive. Inheritance, by its nature, means changing the objects designed to be reused, which will cancel out any benefits of reuse because each new subclassed object then requires testing, the biggest drag on rapid development. Our internal studies show that as much as 60% of the total implementation effort for a client/server system is spent on testing. "The best approach is to treat inheritance as a power tool for churning out objects when appropriate. Inheritance can give you a boost in programmer productivity, but it won't make possible the high degree of reuse that delivers the vital combinition of speed, agility, and power that today's business systems need. "That's the crucial equation for making information technology work: speed + agility + power. By speed, we mean the overall productivity gains from building applications from a store of reusable objects. Power means using the computer to do things that couldn't be done before-integrating hypertext, graphics, video, and Integrated Performance Support, which transmit more information in new ways to knowledge workers. We use the term "agility" because it conveys much more than "flexibility," a feature of object technology comnioiily associated with ease of maintenance. While flexibility-the system's ability to be adapted to new or changing specs-remains all important goal for software, agility refers to the organization as a whole and its ability to change processes and strategies with the nimbleness of a small company. "To build these types of solutions, look to encapsulation. Encapsulation provides for more useful reuse than inheritance because it reduces testing, not just programming. Encapsulated objects project abstract business traits that make them valuable (and reusable!), rather- than inheriting and propagating inflexible, un-reusable code. Moreover, this approach to reuse adds for more value than inheritance does to object-oriented design because it delivers the agile systems organizations need to support continuous reengineering and capitalize on its benefits-accelerating new services and products to market, increasing responsiveness to customers, and supporting new processes and global operations." Jim Adamczyk and Tom Moldauer (Andersen Consulting) Object Magazine, Sept. 1995