A comment on considering "class" harmful

Luigi Lavazza

CEFRIEL - Politecnico di Milano
(Centro per la Ricerca e la Formazione in Ingegneria dell'Informazione)

In his letter published in the Technical Correspondence (Aug. 92, pp. 128-130), Winkler criticizes the concept of class based on the is-a relation. His considerations stem from the observation that inheritance can be viewed from two main perspectives:

- a concept oriented view (COV) concerning logical hierarchies based on the is-a relation;

- program oriented view (POV) concerning physical hierarchies (monotonic extension of types).

The whole discussion assumes the adoption of strictly monotonic inheritance (i.e. a subclass inherits every feature of its father class). This excludes the possibility of using restrictive inheritance, a mechanism provided by popular object-oriented languages like Eiffel and C++. This is a first issue deserving discussion: when should a programmer give up using restrictive inheritance? This decision is the result of a trade-off among the following advantages and shortcomings of restricted inheritance:

1) the problems listed by Winkler, such as undesired features or possibly inconsistent states in the subclass, are all avoided;

2) the substitutability of related objects is no longer perfect; this point can be viewed in the following way: while the generalization hierarchy is the one reported in figure 1, the actual situation is as depicted in figure 2, where class R-S, containing the features that are common to Rectangle and Square, has been introduced.

The main problem with this situation is that run time type errors may arise that cannot be discovered by compilers. An example of such problem is given in figure 3.

     Square S;
     Rectangle R;
     S = new Square(5);        // create a square with side = 5
     R = S;                           // legal instruction: Square is-a Rectangle (Fig. 1)
     x = expr(R.Length);        // error: R is a Square, hence it has no feature named Length

Fig. 3: Run-time type error

Note that the problem described in figure 3 can be easily avoided by adopting a careful programming style [2]. In more complex cases, the usage of an advanced static type checker [1] may help to detect possible run-time type errors.

3) inheritance is strictly related to reusability: when reusing a set of library classes it is much easier to exploit restricted inheritance to "pick up" the interesting features, than to restructure the code in order to create classes (containing just the interesting features) from which the desired classes will be derived. The result of reusing class Rectangle to create class Square is also described by figures 1 and 2.

One important point in Winkler's script is that concept-oriented view in the preliminary phases of development leads to difficulties in the later, programming oriented phases of the process. These difficulties are due to the necessity to transform the is-a based class structure produced by the requirements analysis into a physical hierarchy suitable for being coded.

I completely agree with Winkler's observation that people in charge of the early phases of development should be aware that the results of their work will be converted into programs, where POV dominates. Nevertheless a certain degree of abstraction and COV are inevitable (and actually highly desirable) at the beginning of the software life-cycle. As a consequence, the development process will necessarily involve restructuring the class hierarchy: in this activity a careful usage of non-monotonic hierarchy may help speeding up the process and keeping the number of classes small, and therefore more easily manageable.

A final remark on terminology: the concept of type may be much broader than the concept of class: among the researchers in the language area there is a general consensus in defining the type as a predicate on objects [3]. This implies that, in general, an object will have many (incomparable) types.

Anyway, let's restrict our discussion to the languages where the concept of type corresponds to "being the instance of a class". In my opinion the important point is to clearly understand that there are different concepts of inheritance (COV and POV) and different ways to implement inheritance (monotonic and restricted). Each of these models of class hierarchies has its own features and properties, and people involved in building object-oriented software should be aware of them, in order to best exploit the features of the object-oriented programming approach.

1. Coen-Porisini A., Lavazza L. and Zicari R. The ESSE Project: an overview In Proceedings of The Second Far-East Workshop on Future Database Systems, (Kyoto, Japan, April 1992) World Scientific Singapore 1992, pp. 28-37

2. Grogono P. and Bennett A. Polymorphism and Type Checking in Object-Oriented Languages, SIGPLAN Not. 24, 11, (1989), pp. 109-115

3. Palsberg J. and Schwartzbach M.I. Three Discussions on Object-Oriented Typing ACM OOPS Messenger 3, 2, (1992), pp. 31-38

4. Winkler J.F.H. Objectivism: "Class" considered armful, Communications of the ACM 35, 8, (1992) pp. 128-130