Design Patterns
Proven architectural patterns for building maintainable, extensible, and testable
TypeScript codebases. All 22 Gang of Four patterns with practical implementations.
When to Apply
Reference these patterns when:
- Solving recurring architectural problems
- Refactoring tightly coupled code
- Building plugin/extension systems
- Making code more testable via dependency injection
- Reviewing PRs with architectural concerns
- Choosing between inheritance and composition
Pattern Categories
Creational Patterns
Create objects flexibly, hiding creation logic from consumers.
| Pattern |
Intent |
| Factory Method |
Delegate object creation to subclasses |
| Abstract Factory |
Create families of related objects without concrete types |
| Builder |
Construct complex objects step-by-step |
| Prototype |
Clone existing objects instead of building from scratch |
| Singleton |
Ensure exactly one instance with global access |
See references/CREATIONAL.md for implementations.
Structural Patterns
Compose classes and objects into larger, flexible structures.
| Pattern |
Intent |
| Adapter |
Make incompatible interfaces work together |
| Bridge |
Separate abstraction from implementation |
| Composite |
Treat individual objects and compositions uniformly |
| Decorator |
Attach responsibilities dynamically without subclassing |
| Facade |
Simplify complex subsystem with a unified interface |
| Flyweight |
Share common state to reduce memory across many objects |
| Proxy |
Control access to an object through a substitute |
See references/STRUCTURAL.md for implementations.
Behavioral Patterns
Manage algorithms, responsibilities, and communication between objects.
| Pattern |
Intent |
| Chain of Responsibility |
Pass requests along a handler chain |
| Command |
Encapsulate requests as objects for queuing/undo |
| Iterator |
Traverse collections without exposing internals |
| Mediator |
Centralize complex communication between objects |
| Memento |
Capture and restore object state |
| Observer |
Notify dependents automatically on state changes |
| State |
Alter behavior when internal state changes |
| Strategy |
Swap algorithms at runtime |
| Template Method |
Define algorithm skeleton, let subclasses override steps |
| Visitor |
Add operations to objects without modifying them |
See references/BEHAVIORAL.md for implementations.
Pattern Selection Guide
| Problem |
Pattern(s) |
| Need to decouple object creation |
Factory Method, Abstract Factory |
| Complex object with many optional fields |
Builder |
| Expensive object creation, need copies |
Prototype |
| Global shared resource (config, pool) |
Singleton |
| Incompatible third-party interface |
Adapter |
| Multiple dimensions of variation |
Bridge |
| Tree structures (files, UI, org charts) |
Composite |
| Add features without subclassing |
Decorator |
| Simplify complex API surface |
Facade |
| Thousands of similar objects, memory heavy |
Flyweight |
| Lazy loading, access control, caching |
Proxy |
| Flexible request processing pipeline |
Chain of Responsibility |
| Undo/redo, task queues, macros |
Command |
| Custom collection traversal |
Iterator |
| Many-to-many object communication |
Mediator |
| Snapshots, save/restore state |
Memento |
| Event systems, reactive updates |
Observer |
| Object behavior depends on its state |
State |
| Swappable algorithms (sort, compress, etc) |
Strategy |
| Algorithm with fixed steps, variable parts |
Template Method |
| Operations across heterogeneous objects |
Visitor |
Best Practices
DO
- Choose patterns that solve actual problems you're facing now
- Prefer composition over inheritance
- Use dependency injection to decouple components
- Keep pattern implementations simple — avoid gold-plating
- Document why a pattern was chosen (not just which one)
- Consider testability when choosing patterns
- Combine patterns when appropriate (e.g., Strategy + Factory)
DON'T
- Apply patterns preemptively for hypothetical future needs
- Force a pattern where a simple function/object suffices
- Create unnecessary abstraction layers
- Use Singleton as a disguised global variable
- Choose inheritance when composition works better
- Ignore team familiarity — a simpler pattern everyone knows beats a "better" one nobody understands
SOLID Quick Reference
| Principle |
Summary |
Related Patterns |
| Single Responsibility |
One class, one reason to change |
Strategy, Command, Observer |
| Open/Closed |
Open for extension, closed for modification |
Decorator, Strategy, Template Method |
| Liskov Substitution |
Subtypes must be substitutable for base types |
Factory Method, Abstract Factory |
| Interface Segregation |
Prefer small, focused interfaces |
Adapter, Facade |
| Dependency Inversion |
Depend on abstractions, not concretions |
All patterns using interfaces/abstract |
1---2name: design-patterns3description: Apply Gang of Four design patterns to solve architectural problems in TypeScript. Use when refactoring code architecture, implementing extensible systems, decoupling components, or following SOLID principles. Covers all 22 GoF patterns: Creational (Factory Method, Abstract Factory, Builder, Prototype, Singleton), Structural (Adapter, Bridge, Composite, Decorator, Facade, Flyweight, Proxy), and Behavioral (Chain of Responsibility, Command, Iterator, Mediator, Memento, Observer, State, Strategy, Template Method, Visitor).4---56# Design Patterns78Proven architectural patterns for building maintainable, extensible, and testable9TypeScript codebases. All 22 Gang of Four patterns with practical implementations.1011## When to Apply1213Reference these patterns when:1415- Solving recurring architectural problems16- Refactoring tightly coupled code17- Building plugin/extension systems18- Making code more testable via dependency injection19- Reviewing PRs with architectural concerns20- Choosing between inheritance and composition2122## Pattern Categories2324### Creational Patterns2526Create objects flexibly, hiding creation logic from consumers.2728| Pattern | Intent |29| -------------------- | --------------------------------------------------------- |30| **Factory Method** | Delegate object creation to subclasses |31| **Abstract Factory** | Create families of related objects without concrete types |32| **Builder** | Construct complex objects step-by-step |33| **Prototype** | Clone existing objects instead of building from scratch |34| **Singleton** | Ensure exactly one instance with global access |3536See `references/CREATIONAL.md` for implementations.3738### Structural Patterns3940Compose classes and objects into larger, flexible structures.4142| Pattern | Intent |43| ------------- | ------------------------------------------------------------- |44| **Adapter** | Make incompatible interfaces work together |45| **Bridge** | Separate abstraction from implementation |46| **Composite** | Treat individual objects and compositions uniformly |47| **Decorator** | Attach responsibilities dynamically without subclassing |48| **Facade** | Simplify complex subsystem with a unified interface |49| **Flyweight** | Share common state to reduce memory across many objects |50| **Proxy** | Control access to an object through a substitute |5152See `references/STRUCTURAL.md` for implementations.5354### Behavioral Patterns5556Manage algorithms, responsibilities, and communication between objects.5758| Pattern | Intent |59| ---------------------------- | ------------------------------------------------------- |60| **Chain of Responsibility** | Pass requests along a handler chain |61| **Command** | Encapsulate requests as objects for queuing/undo |62| **Iterator** | Traverse collections without exposing internals |63| **Mediator** | Centralize complex communication between objects |64| **Memento** | Capture and restore object state |65| **Observer** | Notify dependents automatically on state changes |66| **State** | Alter behavior when internal state changes |67| **Strategy** | Swap algorithms at runtime |68| **Template Method** | Define algorithm skeleton, let subclasses override steps |69| **Visitor** | Add operations to objects without modifying them |7071See `references/BEHAVIORAL.md` for implementations.7273## Pattern Selection Guide7475| Problem | Pattern(s) |76| ------------------------------------------ | ----------------------------------- |77| Need to decouple object creation | Factory Method, Abstract Factory |78| Complex object with many optional fields | Builder |79| Expensive object creation, need copies | Prototype |80| Global shared resource (config, pool) | Singleton |81| Incompatible third-party interface | Adapter |82| Multiple dimensions of variation | Bridge |83| Tree structures (files, UI, org charts) | Composite |84| Add features without subclassing | Decorator |85| Simplify complex API surface | Facade |86| Thousands of similar objects, memory heavy | Flyweight |87| Lazy loading, access control, caching | Proxy |88| Flexible request processing pipeline | Chain of Responsibility |89| Undo/redo, task queues, macros | Command |90| Custom collection traversal | Iterator |91| Many-to-many object communication | Mediator |92| Snapshots, save/restore state | Memento |93| Event systems, reactive updates | Observer |94| Object behavior depends on its state | State |95| Swappable algorithms (sort, compress, etc) | Strategy |96| Algorithm with fixed steps, variable parts | Template Method |97| Operations across heterogeneous objects | Visitor |9899## Best Practices100101### DO102103- Choose patterns that solve actual problems you're facing now104- Prefer composition over inheritance105- Use dependency injection to decouple components106- Keep pattern implementations simple — avoid gold-plating107- Document *why* a pattern was chosen (not just which one)108- Consider testability when choosing patterns109- Combine patterns when appropriate (e.g., Strategy + Factory)110111### DON'T112113- Apply patterns preemptively for hypothetical future needs114- Force a pattern where a simple function/object suffices115- Create unnecessary abstraction layers116- Use Singleton as a disguised global variable117- Choose inheritance when composition works better118- Ignore team familiarity — a simpler pattern everyone knows beats a "better" one nobody understands119120## SOLID Quick Reference121122| Principle | Summary | Related Patterns |123| ------------------------- | ---------------------------------------------------- | ---------------------------------------- |124| **S**ingle Responsibility | One class, one reason to change | Strategy, Command, Observer |125| **O**pen/Closed | Open for extension, closed for modification | Decorator, Strategy, Template Method |126| **L**iskov Substitution | Subtypes must be substitutable for base types | Factory Method, Abstract Factory |127| **I**nterface Segregation | Prefer small, focused interfaces | Adapter, Facade |128| **D**ependency Inversion | Depend on abstractions, not concretions | All patterns using interfaces/abstract |
fellipeutaka