Re: OOD, Ada, and Inheritance

[sun-barr!cs.utexas.edu!natinst.com!news.dell.com!milano!cobweb.mcc.com!br eland@ames.arc.nasa.gov (Mark Breland)]

In article <BxGpxt.FDw@cs.uiuc.edu> 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..."