History And Origins Gang Of Four - Learning Module

Loading content...

0/246

Original 23 Patterns

The Canonical Pattern Catalog

The Gang of Four didn't simply compile a list of patterns—they curated a carefully selected catalog that represents the essential building blocks of object-oriented design. The 23 patterns they documented emerged from extensive study of successful systems, academic research, and industrial practice. Each pattern was included only after demonstrating its utility across multiple, independent codebases.

These 23 patterns have become the lingua franca of software design. When a developer in Tokyo says "Observer pattern" to a developer in Berlin, both understand exactly what structure is being described. This shared vocabulary is perhaps the GoF book's greatest contribution—it transformed design discussions from lengthy explanations into precise, efficient communication.

In this page, we'll survey all 23 patterns, organized by their categories: Creational, Structural, and Behavioral. For each pattern, you'll learn its core purpose, when to apply it, and how it relates to others in the catalog.

What You Will Learn

By the end of this page, you will have a mental map of all 23 GoF patterns—their categories, their purposes, and their relationships. This overview prepares you for the detailed pattern-by-pattern study in subsequent chapters, giving you context for where each pattern fits in the larger design landscape.

Understanding Pattern Categories

The Gang of Four organized their patterns into three categories based on what aspect of software design each pattern addresses. Understanding these categories helps you navigate the catalog and identify which patterns might solve a given problem.

Creational Patterns deal with object creation mechanisms. They abstract the instantiation process, making systems independent of how their objects are created, composed, and represented. In essence, they answer the question: How should objects be created?

Creational patterns become important when systems depend on object composition more than class inheritance. As systems evolve to favor composition, correctly instantiating composed objects becomes crucial.

Structural Patterns concern object composition and relationships. They describe how objects and classes can be combined into larger structures while keeping these structures flexible and efficient. They answer: How should objects be composed into larger structures?

Structural patterns help you realize new functionality by composing objects in ways that leverage their individual capabilities.

Behavioral Patterns focus on algorithms and the assignment of responsibilities between objects. They characterize complex control flow that's difficult to follow at runtime. They answer: How should objects interact and distribute responsibilities?

Behavioral patterns shift your focus from understanding control flow to understanding how objects interconnect.

Pattern Categories at a Glance
Category	Focus	Key Question	Pattern Count
Creational	Object creation mechanisms	How should objects be created?	5 patterns
Structural	Object composition	How should objects compose into structures?	7 patterns
Behavioral	Object interaction & responsibility	How should objects interact?	11 patterns

Categories Guide Discovery

When facing a design problem, first identify which category it falls into. If you're struggling with object creation complexity, look at Creational patterns. If you're composing objects into larger structures, consider Structural patterns. If you're dealing with complex interactions or responsibility assignment, explore Behavioral patterns.

Creational Patterns: Controlling Object Creation

Creational patterns abstract the instantiation process. They help make a system independent of how its objects are created, composed, and represented. A system configured with creational patterns knows which objects it works with, but the patterns encapsulate knowledge about which concrete classes the system uses and how instances are created and combined.

Creational patterns become increasingly important as systems evolve toward object composition. Hard-coding a class name commits you to a particular implementation. Creational patterns provide flexibility by letting you defer the decision of which object to create to runtime, to a configuration, or to another part of the system.

The Five Creational Patterns:

Abstract Factory

•Purpose: Provide an interface for creating families of related or dependent objects without specifying their concrete classes.
•Problem it solves: When a system must be independent of how its products are created and must work with multiple families of products.
•Key insight: Encapsulate a group of individual factories that share a common theme. Client code works with factories and products through abstract interfaces.
•Classic example: A UI toolkit that supports multiple look-and-feel standards (Windows, macOS, Linux)—each with its own factory for creating buttons, windows, and scrollbars.

Builder

•Purpose: Separate the construction of a complex object from its representation so that the same construction process can create different representations.
•Problem it solves: When constructing a complex object requires numerous steps and the order or combination of steps varies.
•Key insight: Extract construction logic into a separate Builder object. A Director orchestrates the construction steps while concrete Builders produce the results.
•Classic example: A document converter that reads RTF and builds various outputs (ASCII, TeX, UI widget) using different builders for each format.

Factory Method

•Purpose: Define an interface for creating an object, but let subclasses decide which class to instantiate. Factory Method lets a class defer instantiation to subclasses.
•Problem it solves: When a class can't anticipate the class of objects it must create, or when a class wants its subclasses to specify the objects it creates.
•Key insight: The factory method encapsulates object creation. Subclasses override the factory method to change the class of product created.
•Classic example: A framework for applications that can work with different document types—subclasses override CreateDocument() to create the appropriate document type.

Prototype

•Purpose: Specify the kinds of objects to create using a prototypical instance, and create new objects by copying this prototype.
•Problem it solves: When a system should be independent of how its products are created, composed, and represented, and when instances have only a few combinations of state.
•Key insight: Rather than creating new instances from scratch, clone existing instances. The prototype pattern avoids the cost of creating objects the normal way.
•Classic example: A music editor where notes, rests, and other musical elements are cloned from a palette of prototypes rather than instantiated from classes.

Singleton

•Purpose: Ensure a class has only one instance, and provide a global point of access to it.
•Problem it solves: When exactly one object is needed to coordinate actions across the system.
•Key insight: The class itself controls its instantiation. A private constructor prevents direct instantiation; a static method provides the single instance.
•Classic example: A print spooler, file system, or window manager where the entire system must share a single instance.
•Important caveat: Singleton is often overused and can introduce hidden dependencies. Modern practice favors dependency injection over global singletons.

Creational Pattern Relationships

Abstract Factory is often implemented with Factory Methods, and can be implemented with Prototype. Builder and Prototype can both be used with Singleton. Factory Method is often called from Template Method. These patterns can be combined and substituted based on your specific flexibility needs.

Structural Patterns: Composing Objects into Structures

Structural patterns concern how classes and objects are composed to form larger structures. Structural class patterns use inheritance to compose interfaces or implementations, while structural object patterns describe ways to compose objects to realize new functionality.

The key insight of structural patterns is that simple objects can be combined in sophisticated ways. Rather than creating complex classes with extensive functionality, structural patterns show how to assemble objects such that the composition exhibits desired behavior.

The Seven Structural Patterns:

Adapter

•Purpose: Convert the interface of a class into another interface that clients expect. Adapter lets classes work together that couldn't otherwise because of incompatible interfaces.
•Problem it solves: When you want to use an existing class, but its interface doesn't match what you need.
•Key insight: An adapter wraps an object to provide a different interface to it. It's a translator between two incompatible interfaces.
•Classic example: A drawing editor that can draw geometric shapes but needs to display text elements from a separate text widget toolkit with a completely different interface.

Bridge

•Purpose: Decouple an abstraction from its implementation so that the two can vary independently.
•Problem it solves: When you want to avoid a permanent binding between an abstraction and its implementation, or when both abstractions and implementations should be extensible independently.
•Key insight: Instead of merging abstraction and implementation into one class (potentially with inheritance for variations), separate them into two hierarchies connected by composition.
•Classic example: A portable windowing system where the Window abstraction has multiple implementations for different platforms (X Window, PM, Mac)—the abstraction can evolve independently of platform implementations.

Composite

•Purpose: Compose objects into tree structures to represent part-whole hierarchies. Composite lets clients treat individual objects and compositions of objects uniformly.
•Problem it solves: When you want clients to be able to ignore the difference between compositions of objects and individual objects.
•Key insight: Define a Component interface shared by both primitives and containers. Containers hold and delegate to children, enabling recursive composition.
•Classic example: A graphics application where simple shapes (lines, rectangles) and compound shapes (groups of shapes) share the same interface for rendering and manipulation.

Decorator

•Purpose: Attach additional responsibilities to an object dynamically. Decorators provide a flexible alternative to subclassing for extending functionality.
•Problem it solves: When you need to add responsibilities to individual objects, not to an entire class, and when extension by subclassing is impractical.
•Key insight: A decorator wraps an object, implements the same interface, and adds behavior before/after delegating to the wrapped object. Decorators can be stacked.
•Classic example: A text view widget that can be decorated with scroll capability, border drawing, or drop shadows—each decorator adds one responsibility while delegating core behavior.

Facade

•Purpose: Provide a unified interface to a set of interfaces in a subsystem. Facade defines a higher-level interface that makes the subsystem easier to use.
•Problem it solves: When you want to provide a simple interface to a complex subsystem, or when you want to layer your subsystems.
•Key insight: The facade doesn't add new functionality—it provides a simpler view of existing functionality. Clients can still access the subsystem directly if needed.
•Classic example: A compiler subsystem with classes for scanning, parsing, code generation, etc.—a Compiler facade provides a simple Compile() method while still allowing access to individual components.

Flyweight

•Purpose: Use sharing to support large numbers of fine-grained objects efficiently.
•Problem it solves: When an application uses a large number of objects that have significant shared state, and the storage cost of object proliferation is high.
•Key insight: Separate intrinsic state (shared, stored in flyweight) from extrinsic state (context-dependent, passed in). One flyweight can be reused in many contexts.
•Classic example: A document editor representing each character as an object—flyweights share the character glyph data, while position (extrinsic) is passed from the document structure.

Proxy

•Purpose: Provide a surrogate or placeholder for another object to control access to it.
•Problem it solves: When you need a more versatile or sophisticated reference to an object than a simple pointer—to defer creation, control access, or add behavior.
•Key insight: The proxy maintains a reference to the real subject and implements the same interface. It controls access and may be responsible for creating/deleting the subject.
•Types: Virtual proxy (defers creation), remote proxy (provides local representative for remote object), protection proxy (controls access based on rights), smart reference (adds behavior when accessed).

Structural Pattern Relationships

Adapter changes the interface of an object while Decorator adds responsibilities—but both wrap objects. Composite and Decorator have similar structures but different intents. Bridge is often combined with Abstract Factory to create implementations. Facade often works alongside Adapter, Decorator, and Proxy.

Behavioral Patterns: Managing Interactions and Responsibilities

Behavioral patterns are concerned with algorithms and the assignment of responsibilities between objects. They describe not just patterns of objects or classes but also the patterns of communication between them. They shift your focus from static structure to dynamic, runtime behavior.

Behavioral patterns characterize complex control flow that's difficult to follow at run-time. They help you analyze a system's behavior by focusing on how objects cooperate, rather than tracing through execution paths.

Behavioral class patterns use inheritance to distribute behavior between classes. Behavioral object patterns use object composition to achieve flexible runtime behavior. Object composition allows behavior to be determined dynamically.

The Eleven Behavioral Patterns:

Chain of Responsibility

•Purpose: Avoid coupling the sender of a request to its receiver by giving more than one object a chance to handle the request. Chain the receiving objects and pass the request along the chain until an object handles it.
•Problem it solves: When you want to issue a request to one of several objects without specifying the receiver explicitly.
•Key insight: Each handler either handles the request or passes it to its successor. The client only knows about the first handler in the chain.
•Classic example: A context-sensitive help system where clicking on a widget first checks the widget's help, then the enclosing panel's help, then the dialog's help, and so on up the containment hierarchy.

Command

•Purpose: Encapsulate a request as an object, thereby letting you parameterize clients with different requests, queue or log requests, and support undoable operations.
•Problem it solves: When you need to issue requests to objects without knowing anything about the operation being requested or the receiver of the request.
•Key insight: The Command object decouples the invoker (who issues the request) from the receiver (who performs the action). Commands can be stored, composed, logged, and undone.
•Classic example: A menu system where menu items don't know what action they'll trigger—they simply execute their associated Command object, which encapsulates the action and its receiver.

Interpreter

•Purpose: Given a language, define a representation for its grammar along with an interpreter that uses the representation to interpret sentences in the language.
•Problem it solves: When you have a language to interpret and you can represent statements in the language as abstract syntax trees.
•Key insight: Each grammar rule becomes a class. The abstract syntax tree of a sentence is a composite of these classes. Interpreting the sentence is walking the tree.
•Classic example: A regular expression matcher where each expression type (literal, alternation, sequence, repetition) is a class that knows how to match against input.

Iterator

•Purpose: Provide a way to access the elements of an aggregate object sequentially without exposing its underlying representation.
•Problem it solves: When you want to traverse a collection without exposing its internal structure, or when you want to support multiple traversals simultaneously.
•Key insight: The iterator encapsulates the traversal algorithm. Different iterators can traverse the same collection differently. The collection is unaware of how it's being traversed.
•Classic example: A list class with iterators for forward traversal, backward traversal, or traversal that skips certain elements—clients choose which iterator to use.

Mediator

•Purpose: Define an object that encapsulates how a set of objects interact. Mediator promotes loose coupling by keeping objects from referring to each other explicitly.
•Problem it solves: When a set of objects communicate in complex ways, creating a tight web of dependencies that's hard to understand or change.
•Key insight: Rather than having objects refer to each other directly, they communicate through a mediator. The mediator knows which objects to notify based on events.
•Classic example: A dialog box where a mediator controls interactions between widgets—when a list selection changes, the mediator updates other widgets, disables buttons, etc.

Memento

•Purpose: Without violating encapsulation, capture and externalize an object's internal state so that the object can be restored to this state later.
•Problem it solves: When you need to capture an object's state for later restoration (undo, checkpointing), but exposing internal state would violate encapsulation.
•Key insight: The originator creates a memento containing a snapshot of its state. Only the originator can retrieve state from the memento—others can only store it.
•Classic example: An undo mechanism where each operation saves the old state in a memento before executing; undo restores the state from the memento.

Observer

•Purpose: Define a one-to-many dependency between objects so that when one object changes state, all its dependents are notified and updated automatically.
•Problem it solves: When a change to one object requires changing others, and you don't know how many objects need to change.
•Key insight: Subjects maintain a list of observers and notify them when state changes. Observers register/unregister themselves. The subject doesn't know observer details.
•Classic example: A spreadsheet where cells observing the same data automatically update when that data changes—the data doesn't need to know about the cells.

State

•Purpose: Allow an object to alter its behavior when its internal state changes. The object will appear to change its class.
•Problem it solves: When an object's behavior depends on its state and it must change behavior at runtime depending on that state.
•Key insight: Encapsulate state-specific behavior in separate State classes. The context delegates to its current state object, and state transitions swap this object.
•Classic example: A TCP connection object that behaves differently when in Established, Listening, or Closed states—each state is its own class with appropriate behavior.

Strategy

•Purpose: Define a family of algorithms, encapsulate each one, and make them interchangeable. Strategy lets the algorithm vary independently from clients that use it.
•Problem it solves: When you have many related classes that differ only in their behavior, or when you need different variants of an algorithm.
•Key insight: Extract the algorithm into a Strategy interface with multiple implementations. The context references the strategy and delegates to it.
•Classic example: A text composition system with different line-breaking algorithms (simple, TeX, array)—the algorithm can change without changing the composition client.

Template Method

•Purpose: Define the skeleton of an algorithm in an operation, deferring some steps to subclasses. Template Method lets subclasses redefine certain steps without changing the algorithm's structure.
•Problem it solves: When the invariant parts of an algorithm should be implemented once in a base class, while allowing subclasses to vary the behavior.
•Key insight: The template method defines the algorithm structure and calls abstract 'hook' methods. Subclasses override hooks to customize behavior within the fixed structure.
•Classic example: An application framework where a template method orchestrates document operations (open, read, save)—subclasses override hooks for application-specific behavior.

Visitor

•Purpose: Represent an operation to be performed on the elements of an object structure. Visitor lets you define a new operation without changing the classes of the elements on which it operates.
•Problem it solves: When you have a stable object structure but need to add new operations frequently—modifying every class for each operation is impractical.
•Key insight: Each element class has an accept(visitor) method. The visitor has a visit method for each element type. Double dispatch routes the operation to the right method.
•Classic example: A compiler's abstract syntax tree where type-checking, code generation, and pretty-printing are separate visitors rather than methods on every node class.

Behavioral Pattern Relationships

Strategy and State have nearly identical structures but different intents. Command can use Memento for undo. Iterator often uses Memento to store traversal state. Composite is often traversed using Visitor. Mediator and Observer are both about coordinating multiple objects. Template Method often calls Factory Methods.

Patterns Working Together

Individual patterns solve individual problems. But real systems face multiple design challenges simultaneously. Skilled designers combine patterns, using each where appropriate, to create comprehensive solutions.

The GoF book demonstrates this explicitly with its Lexi case study—a document editor designed throughout Chapter 1 using multiple patterns:

Composite structures the document as a hierarchy of graphical elements
Strategy allows interchangeable algorithms for text formatting
Decorator adds scrolling and borders to viewports
Abstract Factory supports multiple look-and-feel standards
Command implements undo/redo and macro operations
Iterator traverses the document structure

How Patterns Complement Each Other
Pattern Pair	How They Work Together
Abstract Factory + Prototype	Abstract Factory implemented with cloning from prototype instances
Composite + Visitor	Visitor traverses composite structure to perform operations
Command + Memento	Command stores mementos for undo operations
Decorator + Strategy	Decorator adds behavior; Strategy swaps algorithms
Observer + Mediator	Mediator centralizes Observer relationships
Builder + Composite	Builder constructs complex composite structures
State + Flyweight	State objects shared as flyweights across contexts

Think in Pattern Languages

Christopher Alexander's original idea was a 'pattern language'—patterns that work together to solve problems in a domain. The GoF patterns form such a language for object-oriented design. As you gain experience, you'll recognize not just individual patterns, but how they combine into larger solutions.

The Pattern Selection Challenge

With 23 patterns, how do you find the right one for your problem? The GoF book provides several entry points:

By Intent: Each pattern has a one-sentence intent statement. Scanning these can quickly narrow down candidates.

By Problem: What design challenge are you facing?

Creating an object by specifying a class explicitly → Factory Method, Abstract Factory, Prototype
Dependence on specific operations → Chain of Responsibility, Command
Dependence on hardware/software platform → Abstract Factory, Bridge
Tight coupling → Abstract Factory, Bridge, Chain of Responsibility, Command, Facade, Mediator, Observer
Extending functionality by subclassing → Bridge, Composite, Decorator, Observer, Strategy
Inability to alter classes conveniently → Adapter, Decorator, Visitor

By Variation: What aspects of the design might change?

Algorithm → Strategy, Template Method, Visitor
Object being created → Factory Method, Abstract Factory, Prototype
Object state → State, Memento
Object structure → Composite, Flyweight
Object interface → Adapter, Proxy, Decorator
Object implementation → Bridge, Abstract Factory

Avoid Pattern Hunting

A common mistake is searching for a pattern to apply, rather than recognizing a problem that a pattern solves. Patterns should emerge from your analysis of design challenges, not be imposed because you know them. If you find yourself looking for places to apply the Visitor pattern, you're approaching design backwards.

The Pattern Selection Process:

Understand the problem deeply. What aspects might change? What are the forces at play?
Identify the design challenge. Is it about creation, composition, or behavior?
Consider the consequences. Every pattern has trade-offs—flexibility often adds complexity.
Look for known uses. Seeing patterns in familiar systems helps you judge fit.
Start simple. Don't over-pattern. A simple solution that might need refactoring is often better than an over-engineered one that never will.

Summary: The 23 Pattern Overview

Let's consolidate what we've learned about the 23 Gang of Four patterns:

Key Takeaways

•Patterns divide into three categories — Creational (5), Structural (7), and Behavioral (11), based on what aspect of design they address.
•Creational patterns control object creation — They decouple what gets created from how it's created, who creates it, and when.
•Structural patterns compose objects — They show how objects combine into larger structures while maintaining flexibility.
•Behavioral patterns manage interactions — They characterize complex runtime behavior and distribute responsibilities between objects.
•Patterns work together in real systems — Individual patterns solve individual problems; combinations solve real-world design challenges.
•Pattern selection starts with problems, not patterns — Understand your design challenge first, then identify patterns that address it.

What's Next

Now that you have a map of all 23 patterns and their purposes, we'll explore the pattern documentation format that the Gang of Four established. Understanding this format—Intent, Motivation, Structure, Consequences, and more—will help you read pattern descriptions effectively and eventually document patterns of your own.

Page Complete

You now have a comprehensive overview of all 23 Gang of Four patterns. You understand their categories, can identify their purposes, and recognize how they work together. This foundation prepares you for the detailed pattern studies ahead.