Designing Software  «Prev 

General Rules for working with patterns

Describing Design Patterns

How do we describe design patterns? Graphical notations, while important and useful, are not sufficient. They simply capture the end product of the design process as relationships between classes and objects. To reuse the design, we must also record the decisions, alternatives, and trade-offs that led to it. Concrete examples are important too, because they help you see the design in action. We describe design patterns using a consistent format and each pattern is divided into sections according to the following template. The template lends a uniform structure to the information, making design patterns easier to learn, compare, and use.

Pattern Name and Classification

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.


A short statement that answers the following questions:
  1. What does the design pattern do?
  2. What is its rationale and intent?
  3. What particular design issue or problem does it address?


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.


  1. What are the situations in which the design pattern can be applied?
  2. What are examples of poor designs that the pattern can address?
  3. How can you recognize these situations?

  1. Participants: The classes and/or objects participating in the design pattern and their responsibilities.
  2. Collaborations: How the participants collaborate to carry out their responsibilities.
  3. Consequences: 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?

Sample Code

Code fragments that illustrate how you might implement the pattern in C++ or Java.

Known Uses

Examples of the pattern found in real systems. We include at least two examples from different domains.

The first thing you should do is study the pattern so that you are sure you understand it, that it does what you want it to do, and that you can implement it in code.

Map the generic pattern into your specific problem. This involves renaming the participants in the pattern to things that make sense in the context of your application.

Adopting a pattern often requires you to add, remove and reorganize the classes and objects in your system. If you are using UML, CRC cards[1], or any other technique to document your design, you will want to update these to reflect the pattern's use.

You will need to implement the pattern in code. This is often the easiest part of programming with patterns. It is much easier to write code when you have a clear model of how your objects and classes interact and relate to each other, and this is exactly what patterns provide.

[1] CRC cards: (Class, Responsibilities, Collaborators) are an activity bridging the worlds of role-playing games and object-oriented design.