GoF Design Patterns Reference
A comprehensive reference for the Gang of Four design patterns. This skill provides language-agnostic guidance with pseudocode examples that can be translated to any programming language.
When This Skill Activates
This skill automatically activates when you:
- Ask about or need to implement a design pattern
- Need to choose between patterns for a design problem
- Are refactoring code and considering structural improvements
- Discuss architecture, decoupling, or extensibility
- Mention specific patterns: factory, singleton, observer, decorator, etc.
Quick Pattern Reference
Creational Patterns (Object Creation)
| Pattern | Intent | Use When |
|---|---|---|
| Abstract Factory | Create families of related objects | Need platform/theme independence |
| Builder | Construct complex objects step-by-step | Object has many optional parts |
| Factory Method | Let subclasses decide which class to instantiate | Don't know concrete types ahead of time |
| Prototype | Clone existing objects | Object creation is expensive |
| Singleton | Ensure single instance | Need exactly one shared instance |
Structural Patterns (Composition)
| Pattern | Intent | Use When |
|---|---|---|
| Adapter | Convert interface to expected interface | Integrating incompatible interfaces |
| Bridge | Separate abstraction from implementation | Need to vary both independently |
| Composite | Treat individual and groups uniformly | Have tree structures |
| Decorator | Add responsibilities dynamically | Need flexible extension |
| Facade | Simplified interface to subsystem | Complex subsystem needs simple API |
| Flyweight | Share common state efficiently | Many similar objects needed |
| Proxy | Control access to object | Need lazy loading, access control, logging |
Behavioral Patterns (Communication)
| Pattern | Intent | Use When |
|---|---|---|
| Chain of Responsibility | Pass request along handler chain | Multiple handlers, unknown which handles |
| Command | Encapsulate request as object | Need undo, queue, or log operations |
| Interpreter | Define grammar and interpret sentences | Have a simple language to parse |
| Iterator | Sequential access without exposing internals | Need to traverse collections |
| Mediator | Centralize complex communications | Many objects communicate in complex ways |
| Memento | Capture and restore object state | Need undo/snapshot functionality |
| Observer | Notify dependents of state changes | One-to-many dependency |
| State | Alter behavior when state changes | Object behavior depends on state |
| Strategy | Encapsulate interchangeable algorithms | Need to swap algorithms at runtime |
| Template Method | Define skeleton, let subclasses fill in | Algorithm structure fixed, steps vary |
| Visitor | Add operations without changing classes | Need to add many operations to stable structure |
Decision Guide
See Pattern Selection Guide for help choosing the right pattern.
How to Use This Reference
- Choosing a pattern: Start with the decision guide or tables above
- Learning a pattern: Read the full documentation with examples
- Quick reminder: Use the tables above for at-a-glance reference
- Implementation: Follow the pseudocode, adapt to your language
Language Translation Notes
The pseudocode in this reference uses these conventions:
classfor type definitionsfunctionfor methods/functions->for method calls on objects//for comments- Type hints shown as
name: Type
Translate to your language:
- PHP:
class,function,->,//, type hints in docblocks or PHP 8+ - JavaScript/TypeScript:
class,function/arrow,.,//, TS types - Python:
class,def,.,#, type hints - Java/C#: Direct mapping with
new, generics
*Based on concepts from "Design Patterns: Elements of Reusable Object-Oriented Software" by Gamma, Helm, Johnson, and Vlissides (Gang of Four), 1994.*