7 GENERICITYBuilding 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:
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:
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.
|
