Don't fight forces, use them.
R. Buckminster Fuller
This chapter explores the tension between the generality of patterns and the more specific nature of particular pattern implementations. In doing so, we examine the role of software patterns in frameworks and the contrast with generic implementations, reference implementations, and examples.
An important conclusion from Chapter 1 is that a pattern provides a generic solution for a recurring problem: a solution that can be implemented in many ways without necessarily being ‘twice the same’ [Cool98]. We discussed in depth what this means from the perspective of the pattern concept. Specifying what patterns are, however, is just one side of the coin. Developing software with patterns is the other. The following is a code's-eye perspective on the conclusion outlined above:
Each software pattern implementation must consider requirements that may be unique for the concrete context in which it is applied. Any specific implementation of that pattern may therefore be different from other implementations. Unless the variations in the requirements—and consequently those in the solution—can be constrained, enumerated, and matched, it will not be possible to create these different implementations simply by configuring a common generic implementation. Yet any assumption that the requirement space be bounded and limited would be unrealistic.
Requirements come from the context ...