🚀 go-pugleaf

>  Bill Wolfe, wtwolfe@hubcap.clemson.edu

>  One of the reasons I'm not terribly fond of inheritance is that it doesn't
>  correspond to the "natural" way in which reasoning about objects typically
>  proceeds.  We did not first conceive of the general concept of fruit; 
>  rather, we discovered one particular fruit, then another, then another, 
>  and eventually invented fruit as a general concept.  Similarly, one first
>  invents one ADT, then another, then another, and eventually a pattern
>  begins to emerge which seems to be worthy of its own name.  Thus, I 
>  think it more appropriate to simply define abstract classes of types, 
>  characterized by the operations applicable to any type in that class.   

This is true.  However, it is no reason to dislike inheritance.
An abstract class is NOT just a signature, it also includes procedures
that use the undefined operations.  Thus, a subclass only has to implement
a few procedures and then it can use a large number of inherited ones.

Abstractions are hard to find but very valuable.  It is true that
people first generalize from the concrete, but once you have learned
an abstraction then you can generate more concrete instances of it.

One of the things about inheritance is that it makes it easier to find
patterns.  Subclasses naturally have the same interface as superclasses.
Thus, even when you are not worrying about abstractions, and are just
trying to reuse code, you are setting the stage for later reflection
on how to clean up the design and find reusable abstractions.

In general, designs are a lot more reusable than code.  Of course,
most reusable designs exist only in the heads of programmers.
One of the problems in increasing software reuse is how to represent
designs so that they can be shared.  Object-oriented programming
offers an approach to doing this.  Abstract classes are a good
way of describing the design of a data structure.  Frameworks describe
how a set of classes are used together to make an application.

Ralph Johnson