Gang of Four Design Patterns: Catalog Overview and Foundational Concepts

This is the introductory material from *Design Patterns: Elements of Reusable Object-Oriented Software* (Gamma, Helm, Johnson, Vlissides, 1994), commonly known as the "Gang of Four" (GoF) book. It presents the complete catalog of 23 design patterns organized into three categories—Creational, Structural, and Behavioral—along with the foundational framework for understanding what design patterns are, why they matter, and how to apply them.

Key Concepts

• Design pattern: A named, reusable solution to a recurring problem in a context. Originated from Christopher Alexander's architectural patterns. Not a concrete implementation but a template applicable in many situations.
• Four essential elements of a pattern: (1) Pattern name — a shared vocabulary handle; (2) Problem — when to apply it, including preconditions; (3) Solution — elements, relationships, responsibilities, and collaborations; (4) Consequences — trade-offs in flexibility, extensibility, portability, space, and time.
• Three pattern categories:
• Creational (5 patterns): Concern object creation mechanisms; abstract the instantiation process.
• Structural (7 patterns): Concern composition of classes and objects into larger structures.
• Behavioral (11 patterns): Concern algorithms, assignment of responsibilities, and communication between objects.
• Patterns capture evolved solutions — they are not initial designs but reflect redesign and recoding over time toward greater reuse and flexibility.
• Patterns increase design vocabulary — enabling higher-level abstraction in design discussions.
• The book's scope is deliberately limited: no concurrency, distributed programming, real-time, application-domain-specific, UI, device driver, or database patterns.
• Recommended starter patterns for less experienced designers: Abstract Factory, Factory Method, Adapter, Composite, Decorator, Observer, Strategy, Template Method.

Commands and Syntax

No commands per se, but the book establishes a consistent documentation format for each pattern:

• Pattern Name and Classification
• Intent — what does the pattern do?
• Also Known As — alternative names
• Motivation — a scenario illustrating the problem
• Applicability — when to use
• Structure — class/object diagrams
• Participants — classes/objects and their roles
• Collaborations — how participants work together
• Consequences — trade-offs
• Implementation — pitfalls, hints, techniques
• Sample Code — code illustrating implementation
• Known Uses — real-world examples
• Related Patterns — connections to other patterns

Relationships

The 23 Patterns by Category

Creational Patterns (abstract instantiation):

| Pattern | Intent |

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

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

| Builder | Separate construction of a complex object from its representation; same process, different representations |

| Factory Method | Define interface for creating an object; let subclasses decide which class to instantiate |

| Prototype | Create new objects by copying a prototypical instance |

| Singleton | Ensure a class has only one instance with a global access point |

Structural Patterns (composition of classes/objects):

| Pattern | Intent |

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

| Adapter | Convert one interface to another that clients expect |

| Bridge | Decouple abstraction from implementation so both vary independently |

| Composite | Tree structures for part-whole hierarchies; treat individual and composite objects uniformly |

| Decorator | Attach additional responsibilities dynamically; flexible alternative to subclassing |

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

| Flyweight | Use sharing for large numbers of fine-grained objects |

| Proxy | Surrogate or placeholder to control access to another object |

Behavioral Patterns (algorithms and responsibility assignment):

| Pattern | Intent |

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

| Chain of Responsibility | Decouple sender from receiver; pass request along a chain until handled |

| Command | Encapsulate a request as an object; support parameterization, queuing, logging, undo |

| Interpreter | Define a grammar representation and an interpreter for sentences in the language |

| Iterator | Access aggregate elements sequentially without exposing underlying representation |

| Mediator | Encapsulate object interaction; promote loose coupling |

| Memento | Capture and externalize object state without violating encapsulation; enable restore |

| Observer | One-to-many dependency; automatic notification and update on state change |

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

| Strategy | Family of interchangeable algorithms; algorithm varies independently from clients |

| Template Method | Skeleton algorithm in an operation; subclasses redefine certain steps |

| Visitor | Define new operation without changing element classes |

• Patterns cross-reference each other extensively; the book provides a graphical map of relationships (Figure 1.1).
• Patterns can be combined: e.g., Composite with Iterator, Decorator with Strategy, Abstract Factory with Singleton.
• The book's case study (Chapter 2, a document editor) demonstrates how multiple patterns work together in a single system.

Exam-Relevant Points

• 23 patterns total: 5 Creational, 7 Structural, 11 Behavioral — memorize counts and category membership.
• A pattern has four essential elements: name, problem, solution, consequences.
• Christopher Alexander is credited as the origin of the pattern concept (from architecture).
• GoF authors: Erich Gamma, Richard Helm, Ralph Johnson, John Vlissides.
• Creational patterns abstract the instantiation process; Structural patterns deal with composition; Behavioral patterns deal with algorithms and responsibility.
• Key intent phrases are definitional — e.g., "Decorator attaches additional responsibilities dynamically" vs. "Proxy controls access" — know the precise distinction.
• Singleton: only one instance + global access point.
• Factory Method vs. Abstract Factory: Factory Method uses inheritance (subclasses decide); Abstract Factory uses object composition (interface for families).
• Strategy vs. State: Strategy encapsulates interchangeable algorithms; State encapsulates state-dependent behavior (object appears to change class).
• Observer: defines a one-to-many dependency — "when one object changes state, all dependents are notified."
• Template Method vs. Strategy: Template Method uses inheritance to vary parts of an algorithm; Strategy uses delegation to vary the entire algorithm.
• Decorator vs. subclassing: Decorator is a flexible *dynamic* alternative to *static* subclassing for extending functionality.
• Composite: enables uniform treatment of individual objects and compositions — key phrase is "part-whole hierarchies."
• The recommended starter set (Abstract Factory, Factory Method, Adapter, Composite, Decorator, Observer, Strategy, Template Method) represents the most commonly used patterns in practice.