Gang of Four Design Patterns: Catalog Overview and Pattern Fundamentals

This is the foundational reference from *Design Patterns: Elements of Reusable Object-Oriented Software* (Gamma, Helm, Johnson, Vlissides, 1994). It catalogs 23 design patterns organized into three categories — Creational, Structural, and Behavioral — and defines what a design pattern is, its four essential elements, and how patterns capture reusable solutions to recurring object-oriented design problems.

Key Concepts

• Design pattern: A named, reusable solution to a recurring problem in a context — not a concrete design but a template applicable in many situations.
• Four essential elements of a pattern: (1) Pattern name, (2) Problem (when to apply), (3) Solution (elements, relationships, responsibilities), (4) Consequences (trade-offs, costs, benefits).
• Three pattern categories: Creational (object creation), Structural (composition of classes/objects), Behavioral (communication and responsibility assignment between objects).
• 23 patterns total: 5 Creational, 7 Structural, 11 Behavioral.
• Patterns are not novel inventions — they capture proven, recurring solutions from experienced designers that have been applied multiple times in different systems.
• Christopher Alexander's influence: The pattern concept originates from architecture — "each pattern describes a problem which occurs over and over again... and then describes the core of the solution."
• Pattern names raise the level of abstraction — they create a shared vocabulary for discussing design decisions with colleagues.
• Consequences include: flexibility, extensibility, portability, space/time trade-offs, and language/implementation concerns.
• The book's scope is deliberately limited: no concurrency, distributed, real-time, or domain-specific patterns.

Commands and Syntax

No commands per se, but the catalog uses a consistent documentation format for each pattern:

• Pattern Name and Classification
• Intent — what the pattern does (one-sentence summary)
• Also Known As — alternative names
• Motivation — scenario illustrating the problem
• Applicability — when to use
• Structure — class/object diagrams
• Participants — classes/objects and responsibilities
• Collaborations — how participants work together
• Consequences — trade-offs
• Implementation — pitfalls, techniques, language issues
• Sample Code — code illustration
• Known Uses — real-world examples
• Related Patterns — connections to other patterns

Relationships

Creational Patterns (object instantiation):

| Pattern | Intent |

|---------|--------|

| Abstract Factory | Interface for creating families of related objects without concrete classes |

| Builder | Separate construction from representation; same process, different results |

| Factory Method | Defer instantiation to subclasses via an interface |

| Prototype | Create objects by cloning a prototypical instance |

| Singleton | Ensure one instance with a global access point |

Structural Patterns (composition):

| Pattern | Intent |

|---------|--------|

| Adapter | Convert incompatible interfaces |

| Bridge | Decouple abstraction from implementation for independent variation |

| Composite | Tree structures for part-whole hierarchies; uniform treatment |

| Decorator | Dynamic responsibility attachment; flexible alternative to subclassing |

| Facade | Unified higher-level interface to a subsystem |

| Flyweight | Sharing to efficiently support fine-grained objects |

| Proxy | Surrogate/placeholder to control access |

Behavioral Patterns (interaction):

| Pattern | Intent |

|---------|--------|

| Chain of Responsibility | Decouple sender/receiver; pass request along a chain |

| Command | Encapsulate request as object; enables queue, log, undo |

| Interpreter | Grammar representation + interpreter for a language |

| Iterator | Sequential access without exposing representation |

| Mediator | Encapsulate object interaction; promote loose coupling |

| Memento | Externalize state for later restoration without breaking encapsulation |

| Observer | One-to-many dependency with automatic notification |

| State | Alter behavior when internal state changes; appear to change class |

| Strategy | Encapsulate interchangeable algorithms; vary independently from clients |

| Template Method | Algorithm skeleton with subclass-deferred steps |

| Visitor | New operations without changing element classes |

Recommended starting patterns for less experienced designers: Abstract Factory, Factory Method, Adapter, Composite, Decorator, Observer, Strategy, Template Method.

Exam-Relevant Points

• Memorize the 23 patterns by category (5 Creational, 7 Structural, 11 Behavioral) and their one-line intents.
• Four elements of a pattern: name, problem, solution, consequences — expect definitional questions.
• Pattern vs. concrete design: A pattern is a template, not a specific implementation.
• Consequences matter: Patterns always have trade-offs (flexibility vs. complexity, reuse vs. performance).
• Decorator vs. subclassing: Decorator is explicitly described as "a flexible alternative to subclassing for extending functionality."
• Factory Method vs. Abstract Factory: Factory Method defers to subclasses; Abstract Factory creates families of related objects.
• Composite enables uniform treatment: Clients treat individual objects and compositions identically.
• Observer defines one-to-many: When one changes, all dependents update automatically.
• Strategy vs. Template Method: Strategy uses composition (encapsulated algorithms); Template Method uses inheritance (skeleton with overridable steps).
• Command enables undo: Encapsulating requests as objects supports queuing, logging, and undoable operations.
• State pattern: Object "appears to change its class" when state changes — a common trick question.
• The book acknowledges its own incompleteness: It captures "only a fraction of what an expert might know."