In separating the Integer and stack concepts, we notice that only the Integer assignment operation is required by the stack. This observation leads us to parameterize the stack with all data types that provide assignment. Factors important to this generalization process are (1) the interconnection strength of two components, and (2) the position of the used component type in an existing generalization hierarchy.
Interconnection strength is roughly that percentage of the used component's operation semantics used in the interface definition of the using component. The generic stack package, for example, is only weakly connected to the Integer "package", in this case provided for free by the built-in Ada package Standard.
Complementing the notion of interconnection strength is the notion of a generalization hierarchy of components. This is a behavioral hierarchy, rather than an "implementation" hierarchy as in SmallTalk [Gold 83]. The position of a used component in this hierarchy determines, in part, the generalizability of the context.
We see then that the separation of concerns principle is used to separate context from concept, after which the notions of interconnection strength and genericity are applied to parameterize the concept.
It is not always so straightforward to parameterize a component. As an example, consider the concept of a Sort procedure. As with a stack concept, a sort concept can be parameterized by an Element type to be sorted, but, unlike in the stack concept, this base Element type is restricted to those Element types that have an associated total ordering operator. In addition, the Sort concept needs as context a particular ordered collection data type. In languages such as Ada, the operations on both the base Element and ordered collection types must be explicitly provided as a generic parameter, "cluttering" up the parameter list.
generictype Element is private;
with function "<=" (L,R: Element) return Boolean;
type El_Sequence_Ind is (<>);
type El_Sequence is private;
with operations on objects of type El_Sequence;
procedure Sort (Els: in out El_Sequence);
-- requires: "<=" totally orders Element, and
-- El_Sequence operations are (intuitively) as operations
-- on mathematical sequences
-- effects : modifies Els to contain the original values
-- of Els ordered in ascending order determined by "<="
Such "clutter" could be alleviated somewhat by bundling generic type and procedure parameters together into a package parameter (see [Lato 90,Kapu 89])