--- name: gof-patterns description: "Gang of Four design patterns reference. Use this skill when implementing, discussing, or choosing object-oriented design patterns. Auto-activates for architecture decisions, refactoring, and decoupling concerns. Comprehensive coverage of all 23 GoF patterns with pseudocode examples." --- # 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](gof-creational/abstract-factory.md) | Create families of related objects | Need platform/theme independence | | [Builder](gof-creational/builder.md) | Construct complex objects step-by-step | Object has many optional parts | | [Factory Method](gof-creational/factory-method.md) | Let subclasses decide which class to instantiate | Don't know concrete types ahead of time | | [Prototype](gof-creational/prototype.md) | Clone existing objects | Object creation is expensive | | [Singleton](gof-creational/singleton.md) | Ensure single instance | Need exactly one shared instance | ### Structural Patterns (Composition) | Pattern | Intent | Use When | |---------|--------|----------| | [Adapter](gof-structural/adapter.md) | Convert interface to expected interface | Integrating incompatible interfaces | | [Bridge](gof-structural/bridge.md) | Separate abstraction from implementation | Need to vary both independently | | [Composite](gof-structural/composite.md) | Treat individual and groups uniformly | Have tree structures | | [Decorator](gof-structural/decorator.md) | Add responsibilities dynamically | Need flexible extension | | [Facade](gof-structural/facade.md) | Simplified interface to subsystem | Complex subsystem needs simple API | | [Flyweight](gof-structural/flyweight.md) | Share common state efficiently | Many similar objects needed | | [Proxy](gof-structural/proxy.md) | Control access to object | Need lazy loading, access control, logging | ### Behavioral Patterns (Communication) | Pattern | Intent | Use When | |---------|--------|----------| | [Chain of Responsibility](gof-behavioral/chain-of-responsibility.md) | Pass request along handler chain | Multiple handlers, unknown which handles | | [Command](gof-behavioral/command.md) | Encapsulate request as object | Need undo, queue, or log operations | | [Interpreter](gof-behavioral/interpreter.md) | Define grammar and interpret sentences | Have a simple language to parse | | [Iterator](gof-behavioral/iterator.md) | Sequential access without exposing internals | Need to traverse collections | | [Mediator](gof-behavioral/mediator.md) | Centralize complex communications | Many objects communicate in complex ways | | [Memento](gof-behavioral/memento.md) | Capture and restore object state | Need undo/snapshot functionality | | [Observer](gof-behavioral/observer.md) | Notify dependents of state changes | One-to-many dependency | | [State](gof-behavioral/state.md) | Alter behavior when state changes | Object behavior depends on state | | [Strategy](gof-behavioral/strategy.md) | Encapsulate interchangeable algorithms | Need to swap algorithms at runtime | | [Template Method](gof-behavioral/template-method.md) | Define skeleton, let subclasses fill in | Algorithm structure fixed, steps vary | | [Visitor](gof-behavioral/visitor.md) | Add operations without changing classes | Need to add many operations to stable structure | ## Decision Guide See [Pattern Selection Guide](pattern-selection.md) for help choosing the right pattern. ## How to Use This Reference 1. **Choosing a pattern**: Start with the decision guide or tables above 2. **Learning a pattern**: Read the full documentation with examples 3. **Quick reminder**: Use the tables above for at-a-glance reference 4. **Implementation**: Follow the pseudocode, adapt to your language ## Language Translation Notes The pseudocode in this reference uses these conventions: - `class` for type definitions - `function` for 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.*