design-patterns

Related Skills

• Modeling business concepts (Entity, Value Object)? → Use domain-modeling instead
• Restructuring existing code toward a pattern? → Use refactoring for safe migration steps
• Deciding if a pattern is even needed (YAGNI)? → Use principles to evaluate first

Applicability Rubric

Condition	Pass	Fail
Multi-component change	Feature affects multiple components	Single component change
Recognizable problem	Matches known design problem	Unique/novel problem
Flexibility needed	Requires extensible solution	Fixed requirements
Recurring challenge	Solving common design issue	One-off implementation

Apply when: Any condition passes

Core Principles

Pattern Selection Process

1. Identify the problem
   ↓
2. Match problem to pattern category
   ↓
3. Evaluate pattern candidates
   ↓
4. Consider trade-offs
   ↓
5. Apply pattern minimally

Pattern Categories

Category	Purpose	Common Patterns
Creational	Object creation	Factory, Builder, Singleton
Structural	Object composition	Adapter, Decorator, Facade
Behavioral	Object interaction	Strategy, Observer, Command

Pattern Quick Reference

Category	Pattern	Use When	Example
Creational	Factory Method	Object creation varies by context	createLogger(type)
Creational	Builder	Complex object with many optional parts	Fluent configuration
Creational	Singleton	Single instance needed globally	Configuration manager
Structural	Adapter	Interface incompatibility	Wrap legacy API
Structural	Decorator	Add behavior dynamically	Logging wrapper
Structural	Facade	Simplify complex subsystem	Unified API client
Structural	Composite	Tree structures	UI components
Behavioral	Strategy	Algorithm varies at runtime	Payment methods
Behavioral	Observer	One-to-many notifications	Event system
Behavioral	Command	Encapsulate operations	Undo/redo actions
Behavioral	State	Behavior changes with state	Order status

Completion Rubric

Before Applying

Criterion	Pass	Fail
Problem identification	Problem clearly defined	Vague problem statement
Real need	Solves actual problem	Hypothetical/speculative
Simpler alternatives	Considered simpler options first	Jumped to pattern
Team familiarity	Team understands pattern	Pattern is obscure

During Implementation

Criterion	Pass	Fail
Minimal application	Pattern applied minimally	Over-applied
Clear naming	Names reflect pattern intent	Generic/unclear names
Intent preservation	Pattern intent maintained	Pattern misused
Appropriate complexity	Complexity justified	Over-engineered

After Implementation

Criterion	Pass	Fail
Flexibility gained	Code more flexible	Same or less flexible
Documented	Pattern documented if not obvious	Undocumented complexity
Tested	Tests cover pattern behavior	Pattern untested

Anti-Pattern Warning

Pattern Fever: Applying patterns everywhere

Signs:

• Patterns for trivial problems
• Multiple patterns where one suffices
• Code harder to understand than before

Cure: YAGNI - Use patterns only when they solve real problems