Before the Gang of Four, patterns existed as informal, ad-hoc descriptions passed between developers. What made the GoF book transformative wasn't just the identification of patterns—it was the systematic format for documenting them. This format transformed patterns from vague notions into precise, actionable design tools.

The GoF documentation format has become a template for the entire patterns community. When you read a pattern description in a book, article, or documentation, you'll encounter variations of the structure they established. Understanding this format is essential for two reasons: it helps you extract maximum value from pattern documentation, and it prepares you to communicate your own design solutions in a structured way.

In this page, we'll dissect the GoF pattern template, examining each section's purpose and how to use it effectively.

Pattern documentation serves multiple audiences with different needs:

• Learners need to understand the pattern's purpose and when to apply it
• Evaluators need to assess whether a pattern fits their specific problem
• Implementers need structural details and code guidance
• Reviewers need to understand trade-offs and alternatives
• Researchers need to see relationships between patterns and their evolution

A standardized format allows each audience to navigate directly to the information they need. A developer evaluating whether to use the Observer pattern can read Intent and Applicability without wading through implementation details. An implementer already committed to Observer can skip to Structure and Sample Code.

The format also ensures completeness. By requiring authors to address Intent, Motivation, Applicability, Structure, Participants, Collaborations, Consequences, Implementation, Sample Code, Known Uses, and Related Patterns, the format prevents patterns from being documented as "just an idea." Every pattern must be grounded in concrete structure, real-world usage, and explicit consideration of trade-offs.

Intent: The Pattern's Elevator Pitch

The Intent section is a short statement—usually one or two sentences—that describes what the pattern does and what particular design issue or problem it addresses. This is the pattern's "elevator pitch."

A well-written intent serves as a quick filter. Reading intents, you can rapidly scan a catalog and identify patterns worth investigating further. The intent should capture the pattern's essence without unnecessary detail.

Examples of Intent statements from the GoF book:

• Strategy: "Define a family of algorithms, encapsulate each one, and make them interchangeable. Strategy lets the algorithm vary independently from clients that use it."

• Observer: "Define a one-to-many dependency between objects so that when one object changes state, all its dependents are notified and updated automatically."

• Decorator: "Attach additional responsibilities to an object dynamically. Decorators provide a flexible alternative to subclassing for extending functionality."

Notice how each intent captures both the what (what the pattern does) and the why (what benefit it provides).

Also Known As: Aliases and Alternative Names

Patterns often have multiple names, either from different communities, historical evolution, or slight variations. The Also Known As section lists these alternative names.

For example:

• Wrapper is an alias for both Adapter and Decorator
• Publish-Subscribe is an alias for Observer
• Virtual Constructor is an alias for Factory Method

Knowing aliases is practically important. When reading code or documentation that uses a different name, you'll recognize the pattern. When searching for information, you'll know what alternative terms to try.

Making Abstract Concepts Concrete

The Motivation section presents a scenario that illustrates a design problem and how the pattern's structure solves it. This is where the pattern comes alive—where abstract structure becomes concrete solution.

Motivation sections typically:

1. Describe a realistic problem scenario — Not a toy example, but a situation readers recognize. The GoF book uses examples from document editors, graphical frameworks, and compilers.

2. Show why naive solutions fail — Demonstrate that obvious approaches lead to problems: inflexibility, tight coupling, code duplication, etc.

3. Introduce the pattern as a solution — Show how applying the pattern addresses the problems identified.

4. Walk through the solution — Explain how the pattern's structure resolves the forces at play.

Example: The Strategy Pattern's Motivation

The GoF book motivates Strategy with a text composition scenario. A document editor needs to break lines of text. Different algorithms exist (simple, TeX-quality, array-based), and the editor should support multiple algorithms without hard-coding each one.

The naive approach—embedding line-breaking algorithms directly in the composition class with conditionals—creates problems:

• The code becomes complex and hard to maintain
• Adding a new algorithm requires modifying the class
• Clients can't switch algorithms at runtime

The Strategy pattern solves this by:

• Extracting algorithms into separate Compositor classes
• Defining a common interface for all algorithms
• Having the Composition class delegate to a Compositor
• Allowing Compositor objects to be swapped at runtime

Good Motivations Resonate

The best motivation scenarios make you say, "I've faced that exact problem!" or "That's going to happen to me soon." When a motivation resonates with your experience, the pattern becomes not an abstract concept but a tool you're eager to apply.

This is why the GoF chose scenarios from real systems they had built or studied. The document editor, the graphics toolkit, the compiler—these weren't invented for the book. They were actual systems where the patterns had proven their worth.

The Pattern's Entry Criteria

The Applicability section provides explicit guidance on when to use the pattern. It lists the situations in which the pattern applies—the conditions that, when true, suggest this pattern as a solution.

Applicability statements are typically phrased as conditions:

Strategy Applicability (from GoF):

• Many related classes differ only in their behavior. Strategies provide a way to configure a class with one of many behaviors.
• You need different variants of an algorithm.
• An algorithm uses data that clients shouldn't know about. Use Strategy to avoid exposing complex, algorithm-specific data structures.
• A class defines many behaviors, and these appear as multiple conditional statements in its operations. Instead of many conditionals, move related conditional branches into their own Strategy class.

Observer Applicability (from GoF):

• When an abstraction has two aspects, one dependent on the other. Encapsulating these aspects in separate objects lets you vary and reuse them independently.
• When a change to one object requires changing others, and you don't know how many objects need to change.
• When an object should be able to notify other objects without making assumptions about who these objects are.

These three sections together describe the pattern's static and dynamic aspects—what the parts are, how they're organized, and how they interact.

Structure: The Pattern's Architecture

The Structure section presents a graphical representation of the pattern using class and/or object diagrams. In the original GoF book, this used OMT (Object Modeling Technique) notation, a precursor to UML. Modern pattern documentation typically uses UML.

The structure diagram shows:

• The classes and/or objects that participate in the pattern
• Inheritance relationships (is-a)
• Association relationships (has-a, uses-a)
• Dependency relationships
• Interface boundaries

A single diagram captures what would take paragraphs to describe. Study the structure diagram carefully—it's the pattern's blueprint.

Participants: Roles and Responsibilities

The Participants section lists every class and/or object in the pattern's structure, describing each one's responsibilities. This is where you learn what each role does.

Example: Observer Pattern Participants

• Subject — Knows its observers. Any number of Observer objects may observe a Subject. Provides an interface for attaching and detaching Observer objects.

• Observer — Defines an updating interface for objects that should be notified of changes in a Subject.

• ConcreteSubject — Stores state of interest to ConcreteObservers. Sends notification to its observers when its state changes.

• ConcreteObserver — Maintains a reference to a ConcreteSubject object. Stores state that should stay consistent with the Subject's. Implements the Observer updating interface to keep its state consistent with the Subject.

Notice how each participant has clear, bounded responsibilities. This clarity is what makes patterns reusable—you can identify which role each class in your system should play.

Collaborations: Dynamic Behavior

The Collaborations section describes how participants work together to carry out their responsibilities. It focuses on runtime behavior—the sequence of messages and interactions that achieve the pattern's purpose.

Collaborations are often illustrated with sequence diagrams or interaction diagrams. Where Structure shows static organization, Collaborations shows dynamic behavior.

Example: Observer Pattern Collaborations

1. ConcreteSubject notifies its observers whenever a change occurs that could make its observers' state inconsistent with its own.

2. After being informed of a change in ConcreteSubject, a ConcreteObserver object may query the subject for information. ConcreteObserver uses this information to reconcile its state with that of the subject.

This collaboration reveals the push-pull dynamic central to Observer: the subject pushes notification, observers pull specific data they need.

Every Pattern Has a Price

The Consequences section is perhaps the most important for decision-making. It describes the results and trade-offs of applying the pattern—both benefits and liabilities.

Patterns are not free lunches. Each pattern trades one set of design concerns for another. Understanding consequences prevents you from being surprised by the costs of a pattern after you've committed to it.

Consequences typically address:

• Impact on flexibility and extensibility — Does the pattern make the system easier or harder to change?
• Impact on performance — Does the pattern add overhead? Memory? Indirection?
• Impact on complexity — Does the pattern simplify or complicate the design?
• Impact on coupling — Does the pattern increase or decrease dependencies between modules?
• Portability considerations — Does the pattern affect how the code moves between environments?

Notice the Duality

Look at the Observer consequences above. "Unexpected updates" appears as both a benefit and a liability. This illustrates an important pattern truth: the same characteristic can be good or bad depending on context.

• If observers need fresh data continuously, unexpected updates are a benefit.
• If observers do expensive work on each update and updates are frequent, unexpected updates are a liability.

Consequences help you reason about whether the trade-offs are acceptable for your specific situation.

Where the Rubber Meets the Road

The Implementation section provides practical guidance for implementing the pattern—pitfalls to avoid, techniques to consider, and language-specific considerations. This section bridges the gap between abstract pattern structure and working code.

Implementation sections typically cover:

• Key decisions — Choices you must make when implementing the pattern
• Common variations — Different ways to implement the same pattern
• Pitfalls — Mistakes that developers commonly make
• Language considerations — How different language features affect implementation
• Performance considerations — Ways to optimize the pattern's performance

Example: Observer Implementation Considerations

1. Mapping subjects to observers — What data structure should subjects use to store observers? A linked list works but may be slow for many observers. A hash table optimizes lookup but uses more memory.

2. Observing more than one subject — If an observer follows multiple subjects, it must know which subject changed. The update interface may need to pass the subject as a parameter.

3. Who triggers the update? — Should the subject automatically notify observers after each state change, or should clients explicitly trigger notifications after a batch of changes?

4. Dangling references to deleted subjects — What happens if a subject is deleted while observers still reference it? Solutions include having subjects notify observers before destruction or using weak references.

5. Making sure subject state is self-consistent before notification — If a subject notifies observers in the middle of a state change, observers may see inconsistent state. Template Method can help ensure consistency is restored before notification.

Language Evolution Changes Implementation

The GoF book's implementation advice was written for C++ (1994) and Smalltalk. Modern languages offer features that simplify many patterns:

• Lambda expressions make Strategy simpler
• Built-in event systems absorb Observer infrastructure
• Generics eliminate type-safety boilerplate in Factory patterns
• Interfaces with default methods change how patterns compose

When reading implementation sections, translate the advice to your language's idioms. The core insights remain valid; only the mechanics change.

Sample Code: Patterns Made Concrete

The Sample Code section provides code fragments that illustrate how to implement the pattern. In the GoF book, examples use C++ and Smalltalk. The code demonstrates the pattern's key aspects—not a complete application, but enough to see how the pattern translates to code.

Sample code serves several purposes:

• Clarifies the structure — Abstract diagrams become concrete code
• Demonstrates the collaborations — You see how objects interact in practice
• Reveals implementation details — Language-specific idioms become visible
• Provides a starting point — You can adapt the sample to your needs

When reading sample code, focus on understanding what it demonstrates rather than memorizing it. The specific code isn't important; the pattern it illustrates is.

Known Uses: Patterns in the Wild

The Known Uses section provides examples of the pattern in real systems. This grounds the pattern in reality—you're not learning a theoretical construct but a solution that has proven effective in production.

Example: Observer Known Uses (from GoF)

• Smalltalk Model-View-Controller (MVC) architecture
• ET++'s Subject and Observer classes
• InterViews' Widget and WidgetObserver
• Andrew Toolkit's data object dependencies

Known uses provide validation and context. When you see that major, successful systems use a pattern, you gain confidence in its applicability. You can also study these systems for deeper understanding of how the pattern works in practice.

The Three-Uses Rule

The GoF authors had an explicit criterion: a pattern was only included if it appeared in at least three independent systems. This "rule of three" ensures that patterns represent truly reusable solutions, not just one-off designs that happened to work once.

When you see a pattern documented, you can trust that it has been validated across multiple contexts. When you consider documenting your own patterns, apply the same rigor: has this solution proven itself in at least three distinct applications?

Patterns Don't Exist in Isolation

The Related Patterns section describes relationships between the documented pattern and others—patterns that are often used together, patterns that are alternatives, and patterns that address similar problems with different trade-offs.

Relationships fall into several categories:

Complementary patterns — Often used together:

• Command often uses Memento for undo
• Composite often uses Iterator or Visitor for traversal
• Abstract Factory often implements Factory Methods

Alternative patterns — Solve similar problems differently:

• Strategy and State have nearly identical structures but different intents
• Decorator and Strategy both add behavior but in different ways
• Bridge and Adapter both modify interfaces but at different design phases

Enabling patterns — One pattern makes another possible:

• Composite enables Iterator and Visitor
• Abstract Factory enables Singleton factories

Contrasting patterns — Highlight differences through comparison:

• Decorator vs. Subclassing for extending behavior
• Mediator vs. Observer for coordinating objects

Using Related Patterns for Discovery

When a pattern doesn't quite fit your problem, the Related Patterns section points you toward alternatives. If Decorator seems close but not right, checking its related patterns reveals Strategy—which might be what you actually need.

As you learn more patterns, the web of relationships becomes a navigation tool. You don't memorize every pattern; you learn enough to navigate the catalog effectively.

Strategies for Different Needs

How you read a pattern depends on your purpose. Here are reading strategies for different situations:

When learning a pattern for the first time:

1. Read the Intent to understand what the pattern does
2. Study the Motivation thoroughly—understand the problem before the solution
3. Examine the Structure diagram and Participants
4. Read the Consequences to understand trade-offs
5. Skim Sample Code to see it in action
6. Return to Implementation when you're ready to apply it

When evaluating whether to use a pattern:

1. Read the Intent—is this what you're looking for?
2. Check Applicability—does your situation match the conditions?
3. Study Consequences carefully—are the trade-offs acceptable?
4. Check Related Patterns—is there a better fit?

When implementing a pattern you've chosen:

1. Review Structure and Participants for the blueprint
2. Study Collaborations for runtime dynamics
3. Read Implementation for practical guidance
4. Examine Sample Code for concrete examples
5. Check Known Uses for inspiration from real systems

Let's consolidate what we've learned about the pattern documentation format:

What's Next

Now that you understand how patterns are documented, we'll explore the evolution of patterns beyond the original GoF catalog. You'll learn how the patterns movement expanded, what new patterns emerged, how patterns adapted to new paradigms, and the current state of pattern thinking in modern software development.