INVITATION:GENERICITY

##### AN INVITATION TO EIFFEL

### 7 GENERICITY

Building software components (classes) as implementations of abstract data types yields systems with a solid architecture but does not in itself suffice to ensure reusability and extendibility. Two key techniques address the problem: genericity (unconstrained or constrained) and inheritance. Let us look first at the unconstrained form.

To make a class generic is to give it formal generic parameters representing arbitrary types, as in these examples from the Kernel and Data Structure Libraries of EiffelBase:

ARRAY [G]
LIST [G]
LINKED_LIST [G]

These classes describe data structures -- arrays, lists without commitment to a specific representation, lists in linked representation -- containing objects of a certain type. The formal generic parameter G represents this type.

Each of these classes describes a type template. To derive a directly usable type, you must provide a type corresponding to G, called an actual generic parameter; this may be either a basic expanded type (such as INTEGER) or a reference type. Here are some possible generic derivations:

il: LIST [INTEGER]
aa: ARRAY [ACCOUNT]
aal: LIST [ARRAY [[G]]

As the last example indicates, an actual generic parameter may itself be generically derived.

Without genericity, it would be impossible to obtain static type checking in a realistic object-oriented language.

A variant of this mechanism, constrained genericity, will enable a class to place specific requirements on possible actual generic parameters. Constrained genericity will be introduced Previous Chapter Table of Contents Next Chapter

LAST UPDATE: 26 June 1995