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 below, after inheritance. 

