freemo
d9e5668cec
Fixes and improvements from exhaustive audit: Consistency fixes in SKILL.md: - 'Pipe & Filter' → 'Pipe and Filter' (one stray '&' found and corrected) - 'Singleton for factory instance' → clarified to 'register factory as singleton-scoped via DI container' (less misleading wording) - Documentation Format section updated with note that SKILL.md itself is the authoritative source for related-pattern combinations Coverage fix — Related Patterns sections: - Added '## Related Patterns' to ALL 94 pattern files (was 0/94) - Each section lists 3–6 related patterns with relationship descriptions - Covers: why they're related, when to prefer one vs the other, and which are often confused SOLID principles → Creational → Structural → Behavioral → Architectural → Concurrency → Functional → Resilience → Data Access → Messaging → Testing → Error Handling → Microservice — all 13 categories covered Code verification: - Python: 0 failures (all 85 testable blocks pass) - Go: 0 failures (all 76 testable blocks pass) - JavaScript: 0 failures (all 78 testable blocks pass) - All 239 code blocks verified correct after edits Final skill state: - 108 files, 36,524 lines across 13 reference categories - 94/94 pattern files have Related Patterns sections - 2,815-line SKILL.md with 67 decision trees, 23 scenarios, 0 broken references, 0 naming inconsistencies
Behavioral Design Patterns
Behavioral patterns manage algorithms, relationships, and responsibilities between objects. They focus on how objects communicate and how responsibilities are distributed.
All 12 Behavioral Patterns (+ Null Object)
| Pattern | Intent | Key Mechanism | Coupling |
|---|---|---|---|
| Chain of Responsibility | Pass request along a chain of handlers | Linked handlers | Low — sender doesn't know which handler processes |
| Command | Encapsulate a request as an object | Command objects with execute/undo | Low — invoker decoupled from receiver |
| Interpreter | Define a grammar and evaluate sentences | Recursive AST evaluation | Medium — tightly coupled to grammar |
| Iterator | Traverse a collection without exposing internals | next/hasNext interface | Low — collection internals hidden |
| Mediator | Centralize complex communication | Central mediator object | Low between peers; high to mediator |
| Memento | Capture and restore object state | Opaque snapshot objects | Low — caretaker can't modify memento |
| Observer | Notify dependents of state changes | Subject/subscriber registry | Low — subject doesn't know concrete observers |
| State | Change behavior when internal state changes | State objects with transitions | Medium — states know about each other |
| Strategy | Swap algorithms at runtime | Interchangeable strategy objects | Low — client picks strategy |
| Template Method | Define skeleton, let subclasses fill steps | Abstract methods in base class | Medium — subclass coupled to template |
| Visitor | Add operations to objects without modifying them | Double dispatch (accept/visit) | High — visitor knows all element types |
| Null Object | Provide a do-nothing default to avoid null checks | No-op implementation of interface | Low — transparent substitute |
Decision Tree
Need to handle a request?
├─ One handler is enough, but which one is unknown → Chain of Responsibility
├─ Need to queue, log, or undo requests → Command
└─ Need to evaluate structured expressions → Interpreter
Need to traverse a collection?
└─ Want uniform iteration without exposing internals → Iterator
Need objects to communicate?
├─ Many-to-many communication is getting tangled → Mediator
└─ One-to-many: state change should notify others → Observer
Need to manage object state?
├─ Object behavior changes based on state → State
├─ Need to save/restore snapshots → Memento
└─ Need to eliminate null checks → Null Object
Need to vary behavior?
├─ Swap entire algorithm at runtime → Strategy
├─ Fixed skeleton, varying steps → Template Method
└─ Add operations to a class hierarchy without changing it → Visitor
Pattern Relationships
Command ←→ Memento (Command stores memento for undo)
Observer ←→ Mediator (Mediator often uses Observer internally)
State ←→ Strategy (Both delegate to composed objects; State allows transitions)
Iterator ←→ Visitor (Visitor can use Iterator to traverse)
Chain ←→ Command (Chain handlers can be commands)
Template ←→ Strategy (Template uses inheritance; Strategy uses composition)
When to Prefer Composition (Strategy) vs Inheritance (Template Method)
| Factor | Strategy (Composition) | Template Method (Inheritance) |
|---|---|---|
| Algorithm varies independently | Yes | No |
| Need to swap at runtime | Yes | No |
| Multiple varying dimensions | Yes — compose strategies | No — combinatorial explosion |
| Fixed skeleton with hook points | No | Yes |
| Language lacks interfaces | Template Method works | N/A |
Files in This Directory
- chain-of-responsibility.md — Support ticket escalation L1→L2→L3→Manager
- command.md — Text editor with Type/Delete + undo/redo
- interpreter.md — Simple arithmetic expression evaluator
- iterator.md — Fibonacci generator (language-idiomatic)
- mediator.md — Chat room with users communicating through room
- memento.md — Text editor with save/undo snapshots
- observer.md — Weather station with display observers
- state.md — Document workflow: Draft→Review→Published
- strategy.md — Payment processing: CreditCard, PayPal, Crypto
- template-method.md — Data mining with customizable steps
- visitor.md — AST nodes with PrintVisitor and EvalVisitor
- null-object.md — ConsoleLogger vs NullLogger