9.4 Types of Software Patterns

There are as many software pattern formats as there are definitions for patterns, and there are almost as many schools of thought within the patterns community that delineate various flavors of acceptability. The clearest distinction is between generative and non-generative patterns. Conveniently, each type is associated with a particular format for structuring the resulting patterns.

As I've already mentioned, generativity can be seen as a capacity for facilitating a creative resolution to a problem. Generativity is indirect, not coming from the pattern directly but from the creative opportunities that it suggests and makes possible.

Generative patterns are concerned with the act of building. They are meant to embody the Alexandrian ideals, although no one has seriously created a pattern language that matches the scope and ambition of Alexander's.

In generative patterns, the discussion of the problem is most important because it provides the basis for understanding and reworking the solution. The Patron pattern from Jim Coplien (which I will discuss in detail in the section 9.4.1, "CoplienForm" ), is an example of a generative pattern. In it, the discussion of the problem includes the forces and the rationale, as well as the simple problem statement itself. It's left to the reader to figure out the best way to realize the role of a patron for their development project. I call these patterns CoplienForm , after their originator.

On the other hand, a non-generative pattern is instructive, the solution is what's important, and the problem statement is meant to be observational and practical rather than suggestive.

Non-generative patterns are meant to be descriptive and useable as individual statements of best practice ultimately as templates. They are concerned with the artifacts of building using patterns to demonstrate and explain recurring good solutions to normal design problems.

These are frequently called Gamma, or Gang of Four, patterns I'll call them GammaForm patterns. They originated in the book Design Patterns(Gamma 1995),and examples pop up frequently in object-oriented magazines. They're more closely aligned in intent with another definition that Alexander provides:

The pattern is, in short, at the same time a thing, which happens in the world, and the rule which tells us how to create that thing, and when we must create it. It is both a process and a thing; both a description of a thing which is alive, and a description of the process which will generate that thing. (Alexander 1979, 247)

Between these two formats, there's a difference in focus that makes them useful to different audiences and different tasks. The resulting differences in style and usage mean that they both have to be understood by a pattern user wanting to make the most of the patterns that are out there.

But no matter. The purposes are different; the approaches are different. A user of software patterns benefits from the flexibility of different formats and rationales, and from being able to pick and choose patterns to use/reuse without having to worry about the documentation being inappropriately formatted. This is one area in software development in which the lack of a standard is a blessing.

9.4.1 CoplienForm

Here's a breakdown of Coplien's format, by section:

Name
Jim suggests that the name for a pattern should be chosen with as much care as the name for a firstborn child. Although GammaForm names tend to be iconic and "hard" (for example, Fa ade and Adapter), CoplienForm patterns tend to have names that suggest roles or relationships and that describe the solution (for example, Patron or Architect Also Implements).
Problem
The question to be resolved: What task is this pattern helping to make possible? What question is it answering?
Context
This is how you help the pattern practitioner determine the applicability of a pattern. There are two things to consider:
- What larger-scale contextual information is necessary? (For example, language/technical architecture/business domain/infrastructure concerns.)
- What are the critical success factors to this pattern that will make it work or not in a given situation?
Given the absence of a pattern language to provide a context, these two considerations are paramount. Examples can be useful here. Coplien also suggests that if there are any patterns that were expected to have been employed already, they can be mentioned here.
Forces
Oddly enough, a pattern should be both obvious and mind-bending. It should identify the elements that need to be addressed to make it more than a one-off solution or a cliche. At the same time, it should avoid the temptation to be clever at the risk of being impenetrable. The forces in a pattern are where all of this becomes clear. A good pattern can succinctly describe why a solution isn't immediate or straightforward. Or, as Coplien puts it, "What makes this a hard problem? Capture that in a force." Forces also describe the elements that may (preferably should) be in conflict.
Solution
As in real life, solutions are balancing acts. All the forces must be resolved and harmonized. The overall solution must fit the context.
Sketch
Not necessarily a UML diagram or similar object-oriented graphic, this can be a hand-drawn image that represents the forces involved in a symbolic fashion. Coplien suggests that a rough, hand-drawn graphic is actually better because it can be suggestive rather than misleadingly technical.
Resulting context
How has the context changed as a result of the solution?
Rationale
Discuss why the problem exists, what lead to the solution as described, and the motivation behind the pattern. Examples and extended commentary can also be included here.

Here's an example, taken from Coplien's organizational pattern language in PLoP1 (Coplien 1994b):

PATRON

PROBLEM	Giving a project continuity.
CONTEXT	A development organization in which roles are being defined. Patron works only if Developer Controls Process.
FORCES	Centralized control can be a drag. Anarchy can be a worse drag. Most societies need a king/parent figure. An organization needs a single ultimate decision-maker. The time to make a decision should be less than the time it takes to implement it.
SOLUTION	Give the project access to a visible high-level manager who will champion the cause of the project. The patron can be the final arbiter for project decisions, which provide a driving force for the organization to make decisions quickly. The patron is accountable for removing project-level barriers that hinder progress, and is responsible for the organization's "morale" (sense of well being).
RESULTING CONTEXT	Having a patron gives the organization a sense of being and a focus for later process and organizational changes. Other roles can be defined in terms of the patron's role. The manager role is not to be a totally centralized control, but rather to be a champion. That is, the scope of the manager's influence is largely outside those developing the product itself, but includes those whose cooperation is necessary for the success of the product (support organizations, funders, test organizations, and so on). This role also serves as a patron or sponsor; the person is often a corporate visionary.
DESIGN RATIONALE	I have observed this in Phillippe Kahn in QPW; Sethi, et al. in C++ efforts in AT&T; for a manager in a high-productivity Network Systems project; and in another multi-location AT&T project. This relates to the pattern Firewalls. Block talks about the importance of influencing forces over which the project has no direct control The term "pattern" comes from Middle English patron (and the more ancient French patron), which still means both "patron" and "pattern." In the sixteenth century, patron, with a shifted accent, evidently began to be pronounced "patrn;" and it was spelled as "patarne," "paterne," and "pattern." By 1700, the original form ceased to be used of things, and patron/ pattern became differentiated in form and sense. "The original proposed to imitation; the archetype; that which is to be copied; an exemplar (J.); an example or model deserving imitation; an example or model of a particular excellence " from a dictionary of medieval terms. Putting the developer in charge of the process implies that management (see Firewalls) titles become associated with support roles. This works only in a culture in which the manager decides to be the servant of the developer (an insight from NormKerth).

9.4.2 GammaForm

GammaForm patterns are motivated by a concern for good object-oriented design. They describe ways that objects can collaborate and communicate to produce a standard solution, and are not regarded as generative. Instead, they are deliberately observational and descriptive. To the extent that individual patterns are connected, the connections are relationships indirect rather than necessary. Alexander's works are an inspiration, but no more.

In Design Patterns (Gamma et al. 1995), the differences are made clear:

There are no classic examples of software design to draw from, and certainly none that are publicly visible. So, reflection and introspection about your own work and the work of designers you respect becomes an additional source of patterns, as well as established best practices, rules of thumb, and general heuristics.
GammaForm patterns are organized as a catalog, not a language. There is no organic order to their relationships or use. Each pattern can stand alone. The context is not a connection to a higher level, and certainly not to a broader social context. Interestingly enough, one inspiration for taking a catalog approach is the writings of Donald Knuth, who provided Kent Beck (among others) with the inspiration for taking a literate approach to patterns.
GammaForm problems are focused on the solution, not the problem. In fact, the solution descriptions are lengthy and provide the bulk of the value of GammaForm patterns.

Some of the other differences cited in Design Patterns seem to reflect a misunderstanding of Alexander, or at least the kind of misinterpretation that a technologist can make when dealing with the allusive language of the architect or poet. For example, Alexander's Pattern Language is seen as deterministic and prescriptive.

An easy way to see the connection between architectural patterns and GammaForm patterns is to think of objects as building components. Forces are things such as requirements, constraints, and elements of the underlying technical environment that shapes any solution. Then, in the same way that Alexander's patterns describe ways to combine walls, windows, pathways, and eating areas that generate real living spaces, so GammaForm patterns can show time-proven ways to combine objects and classes to create real working, living software.

The format that Gamma and others used in Design Patterns shows the differences with Alexander in form and spirit very clearly:

Pattern name and classification
As with CoplienForm, the name is critical. GammaForm patterns use a name that is almost iconic and captures the essence of solution in as few words as possible. For example, Fa ade is a pattern about using a "unified interface."
Intent
The rationale, motive, and specific problem that the pattern addresses.
Also known as
The pattern may have other names it goes by in the development neighborhood. What are they?
Motivation
This section is a (badly named) textual version of Alexander's picture. A motivation is a "scenario that illustrates the design problem," which provides a practical description of how the pattern solves the problem.
Applicability
A mixture of context and forces. Describes situations in which the pattern is appropriate and guidelines for evaluating its fit.
Structure
A "graphical representation of the classes in the pattern." In the Design Patterns book, this is an OMT class diagram or an interaction diagram from Booch (Gamma et al. 1995). Now, we use UML notation. In effect, a sketch.
Participants
Part of the solution: classes and their responsibilities.
Collaborations
Another part of the solution: how the classes work together to carry out the solution.
Consequences
Yet another part of the solution, this time including a discussion of tradeoffs and results.
Implementation
An extension of the instruction aspect of a solution; issues to think about when applying the pattern.
Sample code
An extension of Implementation, consisting of real-life code examples.
Known uses
Real-world validation where the pattern has been used in existing systems.
Related patterns
Identifies other patterns similar to this one or that this one can be used with.

As you can see, there are many overlaps with CoplienForm patterns. Perhaps the main difference is that GammaForm patterns are specifically didactic, closer to spelled-out versions of Kuhn's exemplars with the solutions added. To the extent that they are concerned with personal and social transformation, it is in an indirect and professional way. For example, Design Patterns talks about the Aha experience:

Once you understand the design patterns and have had an "Aha!" experience with them, you won't ever think about object-oriented design in the same way. You'll have insights that make your designs more flexible, modular, reusable, and understandable. (Gamma et al. 1995, xi)

Unfortunately, GammaForm patterns are typically too long to make it easy to provide an example here. Design Patterns is the best place to go for a detailed introduction.