From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.5-pre1 (2020-06-20) on ip-172-31-74-118.ec2.internal X-Spam-Level: X-Spam-Status: No, score=-0.0 required=3.0 tests=BAYES_40 autolearn=ham autolearn_force=no version=3.4.5-pre1 Date: 10 Nov 92 20:58:10 GMT From: sun-barr!cs.utexas.edu!natinst.com!news.dell.com!milano!cobweb.mcc.com!br eland@ames.arc.nasa.gov (Mark Breland) Subject: Re: OOD, Ada, and Inheritance Message-ID: <1992Nov10.205810.5516@mcc.com> List-Id: In article johnson@cs.uiuc.edu (Ralph Johnson) writes: > >Just as serious a problem with Rosen's paper is the opinion that >polymorphism is optional and can be done by hand when needed. ... > ... >... Rosen seemed to contradict himself when he >talked about why Ada 9X wanted to add support for polymorphism, so >perhaps he doesn't really believe this, but was just trying to explain >why Ada was designed the way it was. ... I saw no contradiction in Rosen's presentation of Ada 9X run-time polymorphism. Rather, it appeared to me he stressed the flexibility of Ada 9X to allow *either* explicitly coded compile-time polymorphism *or* dynamic binding through tagged types. Either mechanism may apply, at the whim of the initial designer. See "Ada 9X: A Technical Summary" by S. Tucker Taft, also in Comms. of the ACM Nov92, for a detailed example of both paradigms. >After 7 years of experience in building object-oriented systems, I >think that polymorphic composition probably has a bigger impact on >program structure than inheritance, but I wouldn't want to give up >inheritance. I enter this arena attempting to reconcile 12 years of experience designing and developing Ada/C/assembly software with a mixture of the good parts of different structured/top down/bottom up methodologies. My background focuses tightly on application construction with little consideration of methodology theory aside from what it can do for me as a tool. Object-oriented design initially struck me as analogous to an old dance partner wearing new threads. New jargon for "commonly" accepted required architecting tasks did not necessarily impress me. Now don't light those flame throwers just yet...I just felt like I'd been using OO techniques years before they were invented. Given real constraints for building a product and budgetary limits for maintaining controllable life cycle costs, I want a method and accompanying toolset that holds its value and usefulness throughout the life of the product. The method/tool cannot be an end, in and of itself. Instead, it must *support* production without forcing designers to twist the design to fit the method paradigm or to spend inordinate amounts of time servicing the tool (to the detriment of iterating the design). With this in mind, although I find much of Rosen's logic sound, I disagree with his assertion that composition and classification are not reconcilable. What we have in common practice is an amorphous blend of the two. I assert that successful designers employ aspects of structured and object oriented methodology to get the job done (do not read "hack" into this). "Implosive" analysis and design marries the results of each successive level of SA/SD and OOA/OOD to define requirements/problem domain, to allocate functionality/abstraction layers, and to determine composition/inheritance reuse of components. SA/SD is not inherently deficient, OOA/OOD is not the unique "second coming", inheritance is not better than composition (or vice versa), and real world developments cannot rely entirely on a single methodology (as now defined) to assure their success. Just as no single program can solve all problems, no single methodology addresses all development domains. In practicality, we really need a "fuzzy" methodology that taps into the strengths of all. >want to have inheritance in my programming languages. I am perfectly >happy for someone to improve it or come up with new ways of doing the >same things, but standard composition is not a replacement for inheritance, >but is instead an addition. (Or inheritance is an addition to composition, >since composition was first.) Thank you for stating the above...that's the first time I have heard a staunch OO persona give credit to the evolution of object-oriented methods, rather than describe it as a radically new invention. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Mark A. Breland | Microelectronics and Computer Project Leader - AFT | Technology Corporation (512) 338-3509 | 3500 West Balcones Drive breland@mcc.com | Austin, Texas 78759-6509 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Mark A. Breland breland@mcc.com "...speaking only for myself, no others and vice versa etc..."