Use when adding new error messages to React, or seeing "unknown error code" warnings.
npx skills add ratacat/claude-skills --skill "design-patterns"
Install specific skill from multi-skill repository
# Description
Use when designing software architecture, refactoring code structure, solving recurring design problems, or when code exhibits symptoms like tight coupling, rigid hierarchies, scattered responsibilities, or difficult-to-test components. Also use when choosing between architectural approaches or reviewing code for structural improvements.
# SKILL.md
name: design-patterns
description: Use when designing software architecture, refactoring code structure, solving recurring design problems, or when code exhibits symptoms like tight coupling, rigid hierarchies, scattered responsibilities, or difficult-to-test components. Also use when choosing between architectural approaches or reviewing code for structural improvements.
Design Patterns
Overview
Design patterns are proven solutions to recurring software design problems. They provide a shared vocabulary for discussing design and capture collective wisdom refined through decades of real-world use.
Core Philosophy: Patterns are templates you adapt to your context, not blueprints to copy. Use the right pattern when it genuinely simplifies your designβnot to impress or over-engineer.
Foundational Principles
These principles underpin all good design:
| Principle | Meaning | Violation Symptom |
|---|---|---|
| Encapsulate What Varies | Isolate changing parts from stable parts | Changes ripple through codebase |
| Program to Interfaces | Depend on abstractions, not concretions | Can't swap implementations |
| Composition Over Inheritance | Build behavior by composing objects | Deep rigid class hierarchies |
| Loose Coupling | Minimize interdependency between objects | Can't change one thing without breaking another |
| Open-Closed | Open for extension, closed for modification | Must edit existing code for new features |
| Single Responsibility | One reason to change per class | Classes doing too many things |
| Dependency Inversion | High-level modules don't depend on low-level | Business logic coupled to infrastructure |
Pattern Selection Guide
By Problem Type
CREATING OBJECTS
βββ Complex/conditional creation βββββββββββ Factory Method
βββ Families of related objects ββββββββββββ Abstract Factory
βββ Step-by-step construction ββββββββββββββ Builder
βββ Clone existing objects βββββββββββββββββ Prototype
βββ Single instance needed βββββββββββββββββ Singleton (use sparingly!)
STRUCTURING/COMPOSING OBJECTS
βββ Incompatible interface βββββββββββββββββ Adapter
βββ Simplify complex subsystem βββββββββββββ Facade
βββ Tree/hierarchy structure βββββββββββββββ Composite
βββ Add behavior dynamically βββββββββββββββ Decorator
βββ Control access to object βββββββββββββββ Proxy
MANAGING COMMUNICATION/BEHAVIOR
βββ One-to-many notification βββββββββββββββ Observer
βββ Encapsulate requests as objects ββββββββ Command
βββ Behavior varies by internal state ββββββ State
βββ Swap algorithms at runtime βββββββββββββ Strategy
βββ Algorithm skeleton with hooks ββββββββββ Template Method
βββ Reduce N-to-N communication ββββββββββββ Mediator
βββ Sequential handlers ββββββββββββββββββββ Chain of Responsibility
MANAGING DATA ACCESS
βββ Abstract data source βββββββββββββββββββ Repository
βββ Track changes for atomic commit ββββββββ Unit of Work
βββ Ensure object identity βββββββββββββββββ Identity Map
βββ Defer expensive loading ββββββββββββββββ Lazy Load
βββ Map objects to database ββββββββββββββββ Data Mapper
βββ Shape data for transfer ββββββββββββββββ DTO
By Symptom
| Symptom | Consider |
|---|---|
| Giant switch/if-else on type | Strategy, State, or polymorphism |
| Duplicate code across classes | Template Method, Strategy |
| Need to notify many objects of changes | Observer |
| Complex object creation logic | Factory, Builder |
| Adding features bloats class | Decorator |
| Third-party API doesn't fit your code | Adapter |
| Too many dependencies between components | Mediator, Facade |
| Can't test without database/network | Repository, Dependency Injection |
| Need undo/redo | Command |
| Object behavior depends on state | State |
| Request needs processing by multiple handlers | Chain of Responsibility |
Domain Logic: Transaction Script vs Domain Model
| Factor | Transaction Script | Domain Model |
|---|---|---|
| Logic complexity | Simple (< 500 lines) | Complex, many rules |
| Business rules | Few, straightforward | Many, interacting |
| Operations | CRUD-heavy | Rich behavior |
| Team/timeline | Small team, quick delivery | Long-term maintenance |
| Testing | Integration tests | Unit tests on domain |
Rule of thumb: Start with Transaction Script. Refactor to Domain Model when procedural code becomes hard to maintain.
Quick Reference
Tier 1: Essential Patterns (Master First)
| Pattern | One-Line | When to Use | Reference |
|---|---|---|---|
| Strategy | Encapsulate interchangeable algorithms | Multiple ways to do something, swap at runtime | strategy.md |
| Observer | Notify dependents of state changes | Event systems, reactive updates | observer.md |
| Factory | Encapsulate object creation | Complex/conditional instantiation | factory.md |
| Decorator | Add behavior dynamically | Extend without inheritance | decorator.md |
| Command | Encapsulate requests as objects | Undo/redo, queuing, logging | command.md |
Tier 2: Structural Patterns
| Pattern | One-Line | When to Use | Reference |
|---|---|---|---|
| Adapter | Convert interfaces | Integrate incompatible code | adapter.md |
| Facade | Simplify complex subsystems | Hide complexity behind simple API | facade.md |
| Composite | Uniform tree structures | Part-whole hierarchies | composite.md |
| Proxy | Control access to objects | Lazy load, access control, caching | proxy.md |
Tier 3: Enterprise/Architectural Patterns
| Pattern | One-Line | When to Use | Reference |
|---|---|---|---|
| Repository | Collection-like data access | Decouple domain from data layer | repository.md |
| Unit of Work | Coordinate atomic changes | Transaction management | unit-of-work.md |
| Service Layer | Orchestrate business operations | Define application boundary | service-layer.md |
| DTO | Shape data for transfer | API contracts, prevent over-exposure | dto.md |
Additional Important Patterns
| Pattern | One-Line | When to Use | Reference |
|---|---|---|---|
| Builder | Step-by-step object construction | Complex objects, fluent APIs | builder.md |
| State | Behavior changes with state | State machines, workflow | state.md |
| Template Method | Algorithm skeleton with hooks | Framework extension points | template-method.md |
| Chain of Responsibility | Pass request along handlers | Middleware, pipelines | chain-of-responsibility.md |
| Mediator | Centralize complex communication | Reduce component coupling | mediator.md |
| Lazy Load | Defer expensive loading | Performance, large object graphs | lazy-load.md |
| Identity Map | Ensure object identity | ORM, prevent duplicates | identity-map.md |
Common Mistakes
| Mistake | Symptom | Fix |
|---|---|---|
| Pattern Overuse | Simple operations require navigating many classes | Only use when solving real problem |
| Wrong Pattern | Code feels forced, awkward | Re-examine actual problem |
| Inheritance Abuse | Deep hierarchies, fragile base class | Favor composition (Strategy, Decorator) |
| Singleton Abuse | Global state, hidden dependencies, hard to test | Use dependency injection instead |
| Premature Abstraction | Interfaces with single implementation | Wait for real need to vary |
Anti-Patterns to Recognize
- God Object: One class does everything β Split using SRP
- Anemic Domain Model: Objects are just data bags β Move behavior to objects
- Golden Hammer: Same pattern everywhere β Match pattern to problem
- Lava Flow: Dead code nobody removes β Delete it, VCS has your back
Modern Variations
| Modern Pattern | Based On | Description |
|---|---|---|
| Dependency Injection | Strategy + Factory | Container creates and injects dependencies |
| Middleware | Decorator + Chain of Responsibility | Request/response pipeline |
| Event Sourcing | Command | Store state changes as events |
| CQRS | Command/Query separation | Separate read/write models |
| Hooks (React/Vue) | Observer + Strategy | Functional lifecycle subscriptions |
Implementation Checklist
Before implementing a pattern:
- [ ] Pattern solves a real problem in this codebase
- [ ] Considered simpler alternatives
- [ ] Trade-offs acceptable for this context
- [ ] Team understands the pattern
- [ ] Won't over-engineer the solution
# Supported AI Coding Agents
This skill is compatible with the SKILL.md standard and works with all major AI coding agents:
Learn more about the SKILL.md standard and how to use these skills with your preferred AI coding agent.