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
Structural Design Patterns
Structural patterns deal with object composition — how classes and objects are assembled to form larger structures while keeping those structures flexible and efficient.
Overview
| Pattern | Intent | Key Mechanism | Complexity |
|---|---|---|---|
| Adapter | Make incompatible interfaces work together | Wraps one interface to match another | Low |
| Bridge | Decouple abstraction from implementation so both vary independently | Composition over inheritance across two dimensions | Medium |
| Composite | Treat individual objects and compositions uniformly | Tree structure with uniform interface | Medium |
| Decorator | Add responsibilities dynamically without subclassing | Wrapping with same interface | Medium |
| Facade | Provide a simplified interface to a complex subsystem | Single entry point delegating to subsystem | Low |
| Flyweight | Share common state among many objects to save memory | Intrinsic vs. extrinsic state separation | High |
| Proxy | Control access to an object via a surrogate | Same interface, interposed object | Medium |
| Module | Encapsulate related functionality behind a public API | Closure / package-level visibility | Low |
When to Reach for a Structural Pattern
- Adapter — You have existing code with an incompatible interface and cannot change it.
- Bridge — You have two independent dimensions of variation (e.g., shape × renderer).
- Composite — You need a tree structure where leaves and branches share the same interface.
- Decorator — You need to add behavior to objects at runtime without modifying their class.
- Facade — You need to simplify interaction with a complex subsystem of many classes.
- Flyweight — You have a huge number of similar objects and memory is a concern.
- Proxy — You need to control access, add lazy loading, caching, or logging around an object.
- Module — You want to group related functions/state and expose only a public API.
Relationship Between Patterns
Adapter vs. Bridge
Adapter fixes an existing interface mismatch after the fact.
Bridge is designed up-front to let abstraction and implementation vary independently.
Adapter vs. Facade
Adapter wraps ONE object to change its interface.
Facade wraps an ENTIRE SUBSYSTEM to simplify it.
Decorator vs. Proxy
Decorator adds new behavior (stacking is common).
Proxy controls access to the original object (usually one layer).
Composite vs. Decorator
Both use recursive composition.
Composite focuses on uniform treatment of tree nodes.
Decorator focuses on adding responsibilities.
Quick Selection Guide
Need to… → Pattern
──────────────────────────────────────────────────
Reuse a class with a wrong interface → Adapter
Vary abstraction & impl independently → Bridge
Build tree structures → Composite
Add behavior without subclassing → Decorator
Simplify a complex subsystem → Facade
Share state across many objects → Flyweight
Control access / lazy-load / log → Proxy
Encapsulate a cohesive module → Module
Files in This Directory
| File | Pattern |
|---|---|
| adapter.md | Adapter |
| bridge.md | Bridge |
| composite.md | Composite |
| decorator.md | Decorator |
| facade.md | Facade |
| flyweight.md | Flyweight |
| proxy.md | Proxy |
| module.md | Module |