🚀 go-pugleaf

   Inheritance has been touted by some as something which "facilitates
   software development ... a mechanism that allows the factorization
   of specifications shared by multiple pieces of software ... in order
   to define a software component that shares the whole specification 
   of another software component, ... indicate that the former inherits
   from the latter, and then specify the differential features of the
   component which is being defined."  But then a serious problem arises:
   inheritance serves not only to suck in the desired _specifications_,
   but the associated _implementations_ as well.  To overcome this,
   "inherited operations can be redefined with new implementations...
   new data components can be added to the internal structure."; but
   this leads to very serious problems.

   The first problem is that regardless of the fact that certain operations
   may have been overridden (redefined), the implementation of the other
   operations has not been modified to account for this fact.  Thus, a
   large percentage of the effort expended by certain inherited operations
   may well be devoted to the maintenance of aspects of the state of the
   base component which are crucial to the correct functioning of the
   operations which have now been overridden.  This introduces major
   inefficiency into each invocation of the inherited operations, and
   constitutes a severe performance penalty.  A cost which could have 
   been paid once and for all at development time (by designing the 
   component efficiently) is now being paid forevermore, at run time.

   The second problem is that the above-mentioned useless state 
   information also consumes space, penalizing us in both dimensions.

   The third problem is that the inherited operations were implemented
   with regard only to the operations provided by the base component.
   However, it is frequently the case that the addition of even a single
   operation has a dramatic impact on the nature of the best solution to
   the implementation problem; since the implementation of the inherited
   operations and the implementation of the non-inherited operations are
   mutually independent, the efficiencies which would have been realized
   had the designer implemented all the operations together are sacrificed,
   resulting again in time and space penalties.

   Since the basic rationale behind software components is the exploitation
   of economies of scale, it makes economic sense to seek an extremely good
   (or perhaps optimal) implementation with little regard to development 
   costs; these costs are spread over thousands or millions of applications 
   and are generally trivially recoverable.  Inheritance is a mechanism which
   seeks to minimize development costs at the probable expense of utilization
   costs, and is therefore something which is of little value to the developer
   of software components, who seeks to sell his product into a market whose
   economic characteristics are essentially those of a commodity market. 

   There may be niche sectors in which utilization costs are relatively
   unimportant and development costs relatively important, such as research
   organizations who are using unique software components as a experimental
   tool for the testing of certain ideas; for such isolated markets, the
   use of inheritance may be appropriate.  There may be situations in which
   the demand pull is so great that inheritance may be useful as a way to
   get an interim solution to market as quickly as possible.  But for the
   majority of the software components industry, an industry built around 
   the supply of highly optimized, widely used, standardized products into 
   a market which is largely commoditized, inheritance is an idea whose time 
   will never come.  


   Bill Wolfe, wtwolfe@hubcap.clemson.edu