omahony@swift.cs.tcd.ie (08/08/90)
> There are two problems here. The last paragraph suggests that the author of a > component decides what may inherit from it, and how. In other words the scope > of re-use is being fixed in the design of the component. My point was that even though the component author would like to produce a highly reusable software component - the design/coding of this component as a class is implicitly fixing the scope of reuse. Just like libraries of procedures, there is a fixed part and a variable part. One could summarize recent progress as follows: Component Representation Change mechanism Procedure Parameter list ADA ADTs parameter list + generics Classes parameter list [+ generics] + inheritance > Although some > object-oriented languages encourage this viewpoint (C++ being one of the worst > offenders, IMHO), for re-use to be valuable in the long-term classes need to be > re-usable in ways which the original author never envisaged. > > inheritance which says "A is like B except ...", meaning the sub-class is NOT > going to conform to some aspects of its parent. Even in cases where you can specify "A is like B except..", you have advanced to: parameter list [+ generics] + more flexible inheritance and you have deprived yourself of some of the encapsulation advantages i.e. you would usually have to know quite a bit about the innards of a class before "removing" some of it's behaviour In conclusion I suggest that as a representation of reusable components, Classes are *probably* better than procedures, but they will not provide quantum leaps in reuse rates for the same reasons that procedures didn't (outside of confined domains e.g. IMSL). This is difficult to *prove*, as studies have not yet been published of experiences with some of the better OOP class libraries (e.g. EIFFEL). Anybody got any *hard* info on this?
hnkst2@unix.cis.pitt.edu (Hanhwe N. Kim) (08/14/90)
In "human factors in computing systems" - CHI'89 conference proceedings pp 69-74, There is an interesting paper by Beth Lange and Tom Moher of the Univ. of Illinois at Chicago concerning a study of reuse by a objective-C programmer. The paper identifies strategies that were used and discusses 'comprehension avoidence' or avoiding deep understanding of details. The subject was experienced in the use of ICpak201. She relied mostly on a copy/edit methodology where a sibling or superclass served as a template. Adjustments were made method-by-method in a linear fashion and verification was done empirically through symbolic execution. Is this a good representation of object oriented programming in general? Are there any comments, rebuttals, or flames?