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 |
Converted and distributed by TomeVault — claim your Tome and manage your conversions.
1---2name: fellipeutaka-leon-design-patterns3description: Design Patterns4---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 |129130---131> Converted and distributed by [TomeVault](https://tomevault.io/claim/fellipeutaka) — claim your Tome and manage your conversions.132<!-- tomevault:4.0:skill_md:2026-04-13 -->
tomevault-io