A middle-out concept of hierarchy (or the problem of feeding the animals)

• Authors: L. S. B. Raccoon; Puppydog P. O. P.
• Venue: ACM SIGSOFT Software Engineering Notes
• Year: 1998

Developers use class hierarchies to model "real world" objects and as metaphors to organize their programs. We (the authors) believe that developers intuitively understand the variety of everyday objects: this cup, that water, those pencils, or in computer terms, this number, that window, those records. We also believe that developers approve of only one concept of class hierarchy, one out of many possible concepts.Many hidden assumptions lurk behind object-oriented inheritance. Traditional object-oriented concepts of hierarchy are obsessively top-down and ignore many obvious bottom-up relationships. Authors who write about object-oriented programming usually define class hierarchies in traditional or archaic terms, referring to the theory of Realism and ancient Greek philosophy. But, just because somebody sees a similarity between concepts in Smalltalk or C++ and concepts described by Plato and other philosophers, does not mean that the perception is appropriate. While the correspondences between classes and concepts from philosophy are interesting, they are not the only possible or useful correspondences. In Women, Fire, and Dangerous Things on page 6, Lakoff writes, "In fact, until very recently, the classical theory of categories was not even thought of as a theory. It was taught in most disciplines not as an empirical hypothesis but as an unquestionable, definitional truth."We want to change that assumption and expand the possibilities of what class hierarchies can be. Specifically, we introduce a cognitive science perspective of objects and the basic level of a class hierarchy. We believe that developers use software classes in a middle-out manner, just like people use linguistic categories. We believe that this middle-out interpretation explains some of the limits to modeling with traditional object-oriented inheritance. We use the basic level to distinguish between the type relationships within a class hierarchy: above the basic level, developers use runtime type relationships, and below the basic, level developers use compile-time type relationships. We also show that developers do program above the basic level.This paper is organized as follows. In the first section, we discuss class and hierarchy from a cognitive science point of view. In the second section, we define the basic level and describe a middle-out concept of hierarchy. In the third section, we explain the developer's version of basic level through the example of "feeding the animals" and show how it relates to type checking. We also describe some of the techniques that developers use to program above the basic level. And, in the fourth section, we argue that many traditional concepts of inheritance fail above the basic level. We argue that the subset and prototype concepts of hierarchy do not work in general, and we argue that Liskov's Substitution Principle and Meyer's Open-Closed Principle only work below the basic level.