home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #26 / NN_1992_26.iso / spool / comp / lang / ada / 3249 < prev    next >
Encoding:
Internet Message Format  |  1992-11-10  |  4.8 KB
  1. Xref: sparky comp.lang.ada:3249 comp.object:4187
  2. Newsgroups: comp.lang.ada,comp.object
  3. Path: sparky!uunet!charon.amdahl.com!pacbell.com!decwrl!sun-barr!cs.utexas.edu!natinst.com!news.dell.com!milano!cobweb.mcc.com!breland
  4. From: breland@cobweb.mcc.com (Mark Breland)
  5. Subject: Re: OOD, Ada, and Inheritance
  6. Message-ID: <1992Nov10.205810.5516@mcc.com>
  7. Sender: news@mcc.com
  8. Nntp-Posting-Host: cobweb.mcc.com
  9. Organization: MCC
  10. References: <2169@snap> <1992Nov9.145313.18741@cis.ohio-state.edu> <BxGpxt.FDw@cs.uiuc.edu>
  11. Date: Tue, 10 Nov 1992 20:58:10 GMT
  12. Lines: 80
  13.  
  14. In article <BxGpxt.FDw@cs.uiuc.edu> johnson@cs.uiuc.edu (Ralph Johnson) writes:
  15. >
  16. >Just as serious a problem with Rosen's paper is the opinion that
  17. >polymorphism is optional and can be done by hand when needed.  ...
  18. >                           ...
  19. >...  Rosen seemed to contradict himself when he
  20. >talked about why Ada 9X wanted to add support for polymorphism, so
  21. >perhaps he doesn't really believe this, but was just trying to explain
  22. >why Ada was designed the way it was.  ...
  23.  
  24. I saw no contradiction in Rosen's presentation of Ada 9X run-time
  25. polymorphism.  Rather, it appeared to me he stressed the flexibility
  26. of Ada 9X to allow *either* explicitly coded compile-time polymorphism
  27. *or* dynamic binding through tagged types.  Either mechanism may apply,
  28. at the whim of the initial designer.  See "Ada 9X: A Technical Summary"
  29. by S. Tucker Taft, also in Comms. of the ACM Nov92, for a detailed
  30. example of both paradigms.
  31.  
  32. >After 7 years of experience in building object-oriented systems, I
  33. >think that polymorphic composition probably has a bigger impact on 
  34. >program structure than inheritance, but I wouldn't want to give up 
  35. >inheritance.
  36.  
  37. I enter this arena attempting to reconcile 12 years of experience designing
  38. and developing Ada/C/assembly software with a mixture of the good parts
  39. of different structured/top down/bottom up methodologies.  My background
  40. focuses tightly on application construction with little consideration
  41. of methodology theory aside from what it can do for me as a tool.
  42. Object-oriented design initially struck me as analogous to an old dance
  43. partner wearing new threads.  New jargon for "commonly" accepted required
  44. architecting tasks did not necessarily impress me.  Now don't light those
  45. flame throwers just yet...I just felt like I'd been using OO techniques
  46. years before they were invented.
  47.  
  48. Given real constraints for building a product and budgetary limits for
  49. maintaining controllable life cycle costs, I want a method and
  50. accompanying toolset that holds its value and usefulness throughout
  51. the life of the product.  The method/tool cannot be an end, in and of itself.
  52. Instead, it must *support* production without forcing designers to twist
  53. the design to fit the method paradigm or to spend inordinate amounts of time
  54. servicing the tool (to the detriment of iterating the design).
  55.  
  56. With this in mind, although I find much of Rosen's logic sound, I disagree
  57. with his assertion that composition and classification are not reconcilable.
  58. What we have in common practice is an amorphous blend of the two.  I assert
  59. that successful designers employ aspects of structured and object oriented
  60. methodology to get the job done (do not read "hack" into this).  "Implosive"
  61. analysis and design marries the results of each successive level of
  62. SA/SD and OOA/OOD to define requirements/problem domain, to allocate
  63. functionality/abstraction layers, and to determine composition/inheritance
  64. reuse of components.
  65.  
  66. SA/SD is not inherently deficient, OOA/OOD is not the unique "second coming",
  67. inheritance is not better than composition (or vice versa), and real world
  68. developments cannot rely entirely on a single methodology (as now defined)
  69. to assure their success.  Just as no single program can solve all problems,
  70. no single methodology addresses all development domains.  In practicality,
  71. we really need a "fuzzy" methodology that taps into the strengths of all.
  72.  
  73. >want to have inheritance in my programming languages.  I am perfectly 
  74. >happy for someone to improve it or come up with new ways of doing the 
  75. >same things, but standard composition is not a replacement for inheritance, 
  76. >but is instead an addition.  (Or inheritance is an addition to composition,
  77. >since composition was first.)
  78.  
  79. Thank you for stating the above...that's the first time I have heard a
  80. staunch OO persona give credit to the evolution of object-oriented
  81. methods, rather than describe it as a radically new invention.
  82.  
  83. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
  84.   Mark A. Breland             |    Microelectronics and Computer
  85.   Project Leader - AFT        |    Technology Corporation 
  86.   (512) 338-3509              |    3500 West Balcones Drive
  87.   breland@mcc.com             |    Austin, Texas 78759-6509
  88. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
  89.  
  90.  
  91. Mark A. Breland
  92. breland@mcc.com  "...speaking only for myself, no others and vice versa etc..."
  93.  
  94.