Microsoft Word OpenIssuesInOO. doc

Type definition. The type and subtype relation is often defined in terms of interfaces:  

• 

A type is a set of interface functions. 

• A 

type 

B is a subtype of A if all interface functions of A are also included in B. In 

addition there are some constraints on the parameters of the interface functions 

depending on whether or not covariance, contra variance or no-variance is supported. 

This however, is not important for the discussion here.  

The problem with such a definition is that the designation (name) of a type has no 

importance. This means that incidental name collapse may result in unintended subtypes. 

Consider the well known example (due to Boris Magnusson) 

Symbol: type 

 (# 

move: 

proc(...); 

   draw: 

proc(...); 

 #) 

 

Cowboy: type 

 (# 

move: 

proc(...); 

   draw: 

proc(...); 

   shoot: 

proc(...); 

 #) 

The type Cowboy is a subtype of Symbol since it includes all the operations of Symbol. 

From a modeling point of view this is not desirable. A type or class represents a concept and 

---

a concept is characterised by its extension, intension and designation. In the above definition 

of type, only the intension is used to characterise the type. The designation is not used in the 

definition of the subtype relation.  

When comparing object-oriented programming to functional programming and 

relational databases, one of the main arguments for object orientation is the explicit support 

for identity of objects. In functional programming and relational databases, only the value of 

attributes are important. Two objects are considered identical if they have the same value. In 

object-oriented programming two objects may have the same value but still be different with 

respect to their identity.  The designation of a type (or class) is analogous to the identity of 

an object. Defining a type without using the designation is a value oriented approach 

eliminating identity for types. (Markuu Sakkinen) 

The above definition of type and subtype is based on the intension and ignoring the 

designation. In some definitions of type and subtype, the extension also seems to be ignored, 

since any object satisfying the interface is considered an instance of the type. 

In the discussion on support for classification it was mentioned that it is often useful to 

be able to describe two or more classifications of the same objects. One way of classifying 

objects is based on the set of interface functions they define. Such a classification leads to a 

classification hierarchy corresponding to a subtype relation based only on interfaces. This 

may in many situations be a useful way of classifying objects, but it should not be the only 

one, and it is not the most important one from a modeling point of view. From a pure 

software engineering point of view it also cannot be useful just to base subtypes on 

interfaces, since this means that one accidentally may replace one object with another just 

based on their interfaces.  

It possible to define a subtype relation that takes the name of the types into account. This 

will then correspond to separating the interface of class from its implementation as 

discussed in the next section.