Eiffel Home Page (Web) -- Getting started with Eiffel (local)
Building software components (classes) as implementations of abstract data types yields systems with a solid architecture but does not in itself 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 as unknown types, as in these examples from ISE's EiffelBase, an open-source library covering basic data structures and algorithms:
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 denotes this type.
A class such as these doesn't quite yet describe a type, but a type template, since G itself denotes an unknown type. To derive a directly usable list or array type, you must provide a type corresponding to G , called an actual generic parameter ; this may be either an expanded type, including basic types 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.
It would not be possible, without genericity, to have 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 described after inheritance.
Eiffel Home Page (Web) -- Getting started with Eiffel (local)
Copyright Interactive Software Engineering, 2001