GoF Patterns MOC
GoF Patterns MOC
Navigation note for all 23 Gang of Four design patterns across creational, structural, and behavioral categories.
Gang of Four (Gamma, Helm, Johnson, Vlissides, 1994) codified 23 patterns across three categories. Use this MOC to navigate to any pattern note. See Design-Patterns-MOC (created Phase 16) for the root vault entry point with cross-layer lineage chains.
Creational Patterns
Object construction — how objects are created and composed. Creational patterns decouple client code from the concrete classes it instantiates.
| Pattern | Intent | Use When |
|---|---|---|
| Factory-Method-Pattern | Defer instantiation to subclasses via a hook method | Client must not know the concrete class; subclass decides the product |
| Abstract-Factory-Pattern | Create families of related objects through a factory interface | System needs product family consistency; swap families atomically |
| Builder-Pattern | Assemble a complex object step-by-step | 4+ parameters (especially optional ones); same steps, different representations |
| Prototype-Pattern | Clone an existing instance as the basis for new objects | Construction is expensive; copy is cheaper; runtime-configured types |
| Singleton-Pattern | One instance, global access (prefer DI-managed scope) | Shared resource requiring identity equality — use DI, avoid getInstance() |
Structural Patterns
Component shapes and composition — how classes and objects are combined into larger structures.
| Pattern | Intent | Use When |
|---|---|---|
| Adapter-Pattern | Convert an interface into one the client expects | Integrating incompatible third-party or legacy interface |
| Bridge-Pattern | Separate abstraction from implementation | Both hierarchies need independent variation |
| Composite-Pattern | Compose objects into tree structures | Client must treat leaf and composite uniformly |
| Decorator-Pattern | Attach responsibilities dynamically | Combinatorial subclassing would otherwise be required |
| Facade-Pattern | Provide a simplified subsystem interface | Subsystem is complex; most clients need a simple path |
| Flyweight-Pattern | Share fine-grained objects to reduce memory | Thousands of near-identical objects consume too much memory |
| Proxy-Pattern | Surrogate to control access to an object | Lazy init, access control, remote stub, or caching needed |
See also: Decorator-vs-Proxy-vs-Adapter — resolves the most common structural confusion.
Behavioral Patterns
Object interaction and responsibility — how objects communicate and distribute responsibility.
| Pattern | Intent | Use When |
|---|---|---|
| Chain-of-Responsibility-Pattern | Pass requests along a handler chain until one handles it | Request sender should not know which handler processes it; handler set changes at runtime |
| Command-Pattern | Encapsulate a request as an object | Undo/redo, queuing, logging, or parameterizing operations needed |
| Interpreter-Pattern | Define a grammar and interpreter for a language | Simple (<=5 rule), stable grammar; use parser generators for anything larger |
| Iterator-Pattern | Sequential access to elements without exposing representation | Traversal over complex structure without coupling to its internals |
| Mediator-Pattern | Centralise complex interactions between peer objects | Many objects interact; reduce mesh coupling to hub-and-spoke |
| Memento-Pattern | Capture and restore object state without breaking encapsulation | Undo/redo or rollback required; state must not be exposed externally |
| Observer-Pattern | Notify dependents automatically when subject state changes | One-to-many event notification; sender should not know its listeners |
| State-Pattern | Alter object behaviour when internal state changes | Object has distinct states with different behaviours; complex conditional state logic |
| Strategy-Pattern | Define interchangeable algorithm family | Algorithm choice varies at runtime; eliminate conditional algorithm selection |
| Template-Method-Pattern | Define algorithm skeleton, defer steps to subclasses | Multiple classes share same algorithm structure with varying steps |
| Visitor-Pattern | Separate operations from element structure | Stable element hierarchy, frequently adding new operations |
Pattern Selection Guide
Use this guide when two patterns seem interchangeable. Pick the one that matches your primary concern.
Chain of Responsibility vs Strategy
- Chain of Responsibility: You have multiple potential handlers and want to find the right one dynamically. Request may pass through several handlers or none.
- Strategy: You have one algorithm slot and want to swap which algorithm fills it. Only one strategy runs.
State vs Strategy
- State: The object's behaviour changes because its own internal state changed. States control their own transitions (
context.setState(...)). - Strategy: The algorithm is swapped externally by the client. The strategy never changes the context's strategy itself.
- See State-Pattern for the detailed comparison callout.
Mediator vs Observer
- Mediator: All colleagues communicate through a central hub. No colleague knows other colleagues directly.
- Observer: One Subject broadcasts to many Observers. Observers know the Subject (at registration time); Subject does not know Observer types.
- See Mediator-Pattern for the detailed comparison callout.
Command vs Strategy
- Command: Encapsulates a specific action on a specific receiver, with state (the receiver, parameters). Supports undo/redo, queuing, logging.
- Strategy: Encapsulates a reusable algorithm with no receiver binding. Stateless (or nearly so). Cannot be undone — no state to restore.
Template Method vs Strategy
- Template Method: Uses inheritance. The abstract class controls the algorithm; subclasses fill in steps. Variation at compile time.
- Strategy: Uses composition. The context delegates the algorithm to an interface. Variation at runtime.
- Prefer Strategy when you need runtime swapping or want to avoid subclass proliferation.
Intent Summary — All 23 Patterns
Quick-reference table for recognition and recall.
| # | Category | Pattern | Intent |
|---|---|---|---|
| 1 | Creational | Factory-Method-Pattern | Defer instantiation to subclasses via a hook method |
| 2 | Creational | Abstract-Factory-Pattern | Create families of related objects through a factory interface |
| 3 | Creational | Builder-Pattern | Assemble a complex object step-by-step |
| 4 | Creational | Prototype-Pattern | Clone an existing instance as the basis for new objects |
| 5 | Creational | Singleton-Pattern | One instance, global access (prefer DI-managed scope) |
| 6 | Structural | Adapter-Pattern | Convert an interface into one the client expects |
| 7 | Structural | Bridge-Pattern | Separate abstraction from implementation hierarchies |
| 8 | Structural | Composite-Pattern | Compose objects into tree structures; treat leaf and composite uniformly |
| 9 | Structural | Decorator-Pattern | Attach responsibilities dynamically without subclassing |
| 10 | Structural | Facade-Pattern | Provide a simplified interface to a complex subsystem |
| 11 | Structural | Flyweight-Pattern | Share fine-grained objects to reduce memory consumption |
| 12 | Structural | Proxy-Pattern | Surrogate to control access to an object |
| 13 | Behavioral | Chain-of-Responsibility-Pattern | Pass requests along a handler chain until one handles it |
| 14 | Behavioral | Command-Pattern | Encapsulate a request as an object |
| 15 | Behavioral | Interpreter-Pattern | Define a grammar and interpreter for a language |
| 16 | Behavioral | Iterator-Pattern | Sequential access to elements without exposing representation |
| 17 | Behavioral | Mediator-Pattern | Centralise complex interactions between peer objects |
| 18 | Behavioral | Memento-Pattern | Capture and restore object state without breaking encapsulation |
| 19 | Behavioral | Observer-Pattern | Notify dependents automatically when subject state changes |
| 20 | Behavioral | State-Pattern | Alter object behaviour when internal state changes |
| 21 | Behavioral | Strategy-Pattern | Define interchangeable algorithm family |
| 22 | Behavioral | Template-Method-Pattern | Define algorithm skeleton, defer steps to subclasses |
| 23 | Behavioral | Visitor-Pattern | Separate operations from element structure |
Sources
- Gamma, Helm, Johnson, Vlissides — Design Patterns: Elements of Reusable Object-Oriented Software, Addison-Wesley, 1994