The pattern's name conveys the essence of the pattern succinctly. A good name is vital, because it will become part of your design vocabulary. The pattern's classification reflects the scheme we introduce in Section 1.5.
A short statement that answers the following questions:
A scenario that illustrates a design problem and how the class and object structures in the pattern solve the problem. The scenario will help you understand the more abstract description of the pattern that follows.
A graphical representation of the classes in the pattern using a notation based on UML. We use interaction diagrams, also.
The classes and/or object participating in the design pattern and their responsibilities.
How the participants collaborate to carry out their responsibilities.
How does the pattern support its objectives? What are the trade-offs and results of using the pattern? What aspect of system structure does it let you vary independently?
What pitfalls, hints or techniques should you be aware of when implementing the pattern? Are there language-specific issues?
Code fragments that illustrate houw you might implement the pattern in C++ or Smalltalk.
Examples of the pattern found in real systems. We include at least two examples from different domains.
What design patterns are closely related to this one? What are the important differences? With which other patterns should this one be used?