Gang of Four Design Patterns

The Gang of Four

The Gang of Four (GoF) — Erich Gamma, Richard Helm, Ralph Johnson, and John Vlissides — published "Design Patterns: Elements of Reusable Object-Oriented Software" in 1994. This book catalogued 23 classic design patterns that have become the vocabulary of OO design.

Design patterns are proven solutions to common design problems. They're not code you copy-paste — they're templates for solving recurring issues in a disciplined way.

The 23 GoF Patterns

Creational Patterns (5) — How objects are created
┌──────────────────────────────────────────────────────┐
│ Pattern         │ Purpose                            │
├─────────────────┼────────────────────────────────────┤
│ Abstract Factory│ Create families of related objects  │
│ Builder         │ Construct complex objects step-by-step│
│ Factory Method  │ Delegate instantiation to subclasses│
│ Prototype       │ Clone existing objects             │
│ Singleton       │ Ensure only one instance exists    │
└─────────────────┴────────────────────────────────────┘

Structural Patterns (7) — How classes are composed
┌──────────────────────────────────────────────────────┐
│ Pattern         │ Purpose                            │
├─────────────────┼────────────────────────────────────┤
│ Adapter         │ Convert one interface to another   │
│ Bridge          │ Separate abstraction from impl.    │
│ Composite       │ Treat individual & groups uniformly│
│ Decorator       │ Add responsibilities dynamically   │
│ Facade          │ Simplify a complex subsystem       │
│ Flyweight       │ Share common state efficiently     │
│ Proxy           │ Control access to an object        │
└─────────────────┴────────────────────────────────────┘

Behavioral Patterns (11) — How objects communicate
┌──────────────────────────────────────────────────────┐
│ Pattern         │ Purpose                            │
├─────────────────┼────────────────────────────────────┤
│ Chain of Resp.  │ Pass requests along a chain        │
│ Command         │ Encapsulate requests as objects    │
│ Interpreter     │ Define grammar and interpret it    │
│ Iterator        │ Access elements sequentially       │
│ Mediator        │ Centralize complex communications  │
│ Memento         │ Capture and restore state          │
│ Observer        │ Notify dependents of changes       │
│ State           │ Alter behavior when state changes  │
│ Strategy        │ Swap algorithms at runtime         │
│ Template Method │ Define skeleton, override steps    │
│ Visitor         │ Add operations without changing    │
└─────────────────┴────────────────────────────────────┘

How to Choose a Pattern

Patterns aren't chosen randomly — they're solutions to specific problems. Here's a decision guide:

Problem → Pattern

Need exactly one instance?
  → Singleton

Need to create objects without specifying exact class?
  → Factory Method or Abstract Factory

Need to build complex objects step by step?
  → Builder

Need to add behavior to objects dynamically?
  → Decorator

Need to simplify a complex subsystem?
  → Facade

Need to notify many objects when one changes?
  → Observer

Need to swap algorithms at runtime?
  → Strategy

Need to encapsulate requests as objects?
  → Command

Need to treat individual and composite objects uniformly?
  → Composite

Need to adapt one interface to another?
  → Adapter

Pattern Relationships

Patterns often work together. Understanding how they relate helps you choose the right combination:

Common Pattern Combinations:

Factory Method + Strategy
  ── Create objects with Factory, use Strategy for behavior
  PaymentProcessor = PaymentFactory.create(type)
  processor.pay(amount)  // Strategy determines how

Decorator + Composite
  ── Both deal with wrapping/extending objects
  Component decorator = new LoggingDecorator(component)
  Component tree = new Composite(list of components)

Observer + Mediator
  ── Both manage communication between objects
  Observer: objects subscribe to events
  Mediator: central hub coordinates communication

Adapter + Facade
  ── Both simplify interfaces
  Adapter: converts one interface to another
  Facade: provides simple interface to complex subsystem

Template Method + Strategy
  ── Both handle algorithm variation
  Template: override specific steps in a fixed algorithm
  Strategy: swap entire algorithms

Anti-Patterns to Avoid

Just as there are good patterns, there are bad patterns (anti-patterns) that signal design problems:

Common Anti-Patterns:

1. God Object
   One class that does everything.
   → Apply SRP, extract responsibilities.

2. Spaghetti Code
   Unstructured, tangled code with no clear flow.
   → Apply Template Method, Strategy.

3. Golden Hammer
   Using the same pattern everywhere.
   → Use the RIGHT pattern for the problem.

4. Poltergeist
   Classes with only one method that do no real work.
   → Merge into the class that uses it.

5. Lava Flow
   Dead code that no one dares to remove.
   → Delete it. Run tests. Move on.