The approach we use to design a generic architecture is based on the separation of concerns principle [Hest 81]. Such an architecture is designed as a collection of integrated components, each with a particular concern implemented as content. Our goal is to define these components to be minimal in the sense that each represents exactly one concern. Of course, this goal is tempered somewhat by both the difficulty in achieving such minimality, and by the inefficiencies sometimes caused by this separation. For example, the concerns of syntax and semantic analysis in a compiler can be combined for efficiency, but this optimization is difficult to do by the compiler once these concerns have been separated.
The separation of concerns principle guides us in decomposing a component implementation into "minimal" subcomponents. At the same time it helps us to generalize a part for a wider domain. That is, in decomposing a component into its sub-components, we can separate out the essence of a domain independent algorithm from those parts of the content that are just one of many contextual choices across a wider domain.
Consider the concept of an Integer Stack. We can easily separate the underlying stack concept from the concept of the data type Integer, separating out the choice of Integer as a contextual decision. This leaves us with the concept of Integer to "plug into".
generictype Element is private;
package Stacks is
type Stack is private;
procedure Push(E: in Element;
S: in out Stack);