Reusable Objects and Reliability

David Essex

Object-oriented languages often provide generic classes (also called parameterized or template classes) that can organize or operate on other classes. A compiler must ensure that only objects that can be safely operated on are stipulated for use by these generic classes. Eiffel accomplishes this with a technique called constrained genericity .

For example, if you wanted a banking program to search through a list for valid customer names, you might reuse a generic class that was already created for the task. Say the generic class KEY_LIST is available for handling keyed items. To avoid parameter mismatches, you would constrain KEY_LIST to operate only on items of type MATCHABLE, stating this in the class header class KEY_LIST[T->MATCHABLE] .

To use this class, you'd have class CUSTOMER inherit from class MATCHABLE, which contains the code that verifies that a given class contains only members starting with, say, an integer. The list is declared this way: customers:KEY_LIST[CUSTOMER] . The relationship of these classes is shown in the figure (the root class BANK is the class that calls objects and starts the whole bank program off).

C++ can enforce similar restrictions for generic classes, but they are not stated explicitly, as they are in Eiffel. Instead, a C++ compiler does not verify that a parameter type is supported until a client creates an instance of a generic class. The only possible way to check for proper use of generic classes is for the programmer to closely examine the code line by line.

---

Class R elationships

illustration_link (11 Kbytes)

CUSTOMER inherits its type-validation code from MATCHABLE and becomes the parameter used to constrain the generic class KEY_LIST. The latter is a container class whose members all begin with a key (e.g., an integer).