Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!tut.cis.ohio-state.edu!unmvax!gatech!hubcap!wtwolfe From: wtwolfe@hubcap.clemson.edu (Bill Wolfe) Newsgroups: comp.sw.components Subject: Inheritance vs. component efficiency Message-ID: <5682@hubcap.clemson.edu> Date: 4 Jun 89 01:29:05 GMT Organization: Clemson University, Clemson, SC Lines: 63 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