implementation-design-patterns

TypeScript Design Patterns Best Practices (Refactoring Guru)

Implementation reference for the 22 Gang of Four design patterns in TypeScript, distilled from refactoring.guru. Each of the 22 pattern files across 3 categories captures intent, problem, solution, applicability, a runnable TypeScript example, implementation steps, pros/cons, and relations to sibling patterns.

The patterns are a vocabulary for structural decisions, not a prescription. Reach for a pattern only when its applicability criteria match the problem at hand — every pattern entry includes a When NOT to Use section to guard against over-engineering.

When to Apply

• Refactoring a class that has grown unwieldy via inheritance — combinatorial subclasses, conditional branching on type, or a "god class" with many responsibilities
• Designing a new module whose collaborators are not yet fixed — you want to keep the interface stable while implementations vary
• Integrating an incompatible third-party API, library, or legacy class into existing code
• Modeling a tree-shaped domain (file systems, organization charts, expression ASTs, UI component trees) where leaves and branches must be treated uniformly
• Adding cross-cutting behavior at runtime — logging, caching, access control, decoration — without subclassing
• Selecting an algorithm or behavior variant at runtime based on configuration, user input, or environmental conditions
• Implementing undo/redo, history snapshots, transactional rollback, or scheduling/queueing of operations
• Coordinating many objects whose direct mutual references have become tangled — a hub that brokers communication
• Notifying many subscribers when something changes — event systems, reactive data flows
• Reviewing code that smells like a pattern is implicit (large switch on kind, parallel class hierarchies, identical algorithm skeletons across siblings) — make it explicit

Rule Categories