johnson@p.cs.uiuc.edu (05/15/89)
By Kevin McEntee >Can code sharing outside of the natural >taxonomy of the problem space happen gracefully? Of course it can! Look at Set and Dictionary. In Smalltalk, inheritance is primarily code sharing. Taxonomy is of secondary importance. In Eiffel, the reverse is true. Moreover, the type system of Eiffel ensures that a subclass must be a subtype. This is clearly not always the case in Smalltalk. Thus my type system for Smalltalk (see OOPSLA'86 paper) distinguishes types and classes. There are actually quite a few different uses of inheritance in Smalltalk. Code-sharing inheritance replaces copy-and-hack as a way to reuse code that was not designed to be reused. Inheritance of abstract classes provides the fill-in-the-blank programming style of program templates (another form of software reuse). Inheriting and specializing a concrete class is the kind of inheritance that the text-books present as ideal. Of the three, pure code-sharing is the ugliest. However, it is very important during prototyping. Inheritance of abstract classes is the most elegant, but it requires abstract classes, which are hard to find. I tend to use inheritance in a ugly fashion when I am building the first version of a system, but I always clean up the system and find abstract classes before I finish with it. Note that pure code-sharing is not always ugly, and it isn't always possible to find abstract classes.