johnson@m.cs.uiuc.edu (08/09/90)
omahony@swift.cs.tcd.ie >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. However, the fixed part of a class are * the instance variables * the interface You can always add new instance variables, but you can never delete them. You can always extend the interface. Some languages, like C++, don't let you change the inherited interface at all. Languages with no static type-checking do not put specific limits on how you change the inherited interface, but there are always practical limits imposed by the users of the class. However, you can ALWAYS override procedures. If you can't, it isn't OOP. Thus, non-virtual functions in C++ are not OOP. >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 There are many different uses of inheritance. Some do not change the superclass at all and do not require much knowledge of it. These uses could be replaced by using components, instead. Abstract superclasses have a well defined interface that subclasses must meet. They are essentially designs for subclasses. On the other extreme, subclasses just replaces making a copy and editing, with no regard to reusing interface. Naturally, this requires knowing a lot about the implementation of the class. It would be better if you didn't have to do it, but then it would be better if people wrote their programs to be reusable in the first place. "Subclassing to edit" is better than the alternative. >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). My experience in Smalltalk is that we do get quantum leaps in reuse rates. I still haven't figured out exactly why. The language is the least of the reasons, the programming environment, the class libraries, and the culture are more important reasons. At the last OOPSLA, Knowlege Systems Corporation gave statistics for the last eight or nine projects that they had done. They had reuse figures of from 50% to 95%, with something like 85% being the median. Ralph Johnson - University of Illinois at Urbana-Champaign