freemo
98680825a7
Adds a comprehensive opencode skill under .opencode/skills/programming-patterns/
covering 90+ design, architectural, concurrency, and functional patterns.
- 108 files, 33,500+ lines across 13 reference categories
- Every pattern: pseudocode + tested Python + Go + JavaScript implementations
- All 239 code blocks verified passing (85 Python, 76 Go, 78 JS)
- 1,569-line SKILL.md with:
- Master decision tree (all 14 categories with multi-pattern suggestions)
- 34 situation-specific decision trees covering every programming scenario
(new feature, refactoring, REST API, CLI, data pipeline, rule engine,
external integration, performance, memory, notifications, plugins,
caching, events, auth, reporting, vendor lock-in, domain model,
business rules, observability, file I/O, scheduling, testability,
third-party libs, concurrency, complex domain interactions)
- 12 compound pattern-combination scenarios with full architecture maps
(e-commerce checkout, REST endpoint, background jobs, real-time dashboard,
microservice resilience, ML pipeline, text editor, legacy migration,
multi-tenant SaaS, document approval, financial transactions, chat)
- 'When Am I Allowed to Skip Patterns?' mandate table (answer: never)
- Quick pattern lookup tables for all 90+ patterns
- Complete reference index
3.6 KiB
3.6 KiB
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 |