cookieMonsterDev Design Patterns
Ground design-pattern answers in the reference files bundled with this skill instead of improvising definitions. Each pattern has a reference file explaining it and a folder of runnable examples in popular languages.
When to Use
- The user names a pattern directly ("show me the builder pattern in Rust")
- The user describes a design problem that maps to a pattern ("I need to create objects without specifying their concrete class")
- The user asks to compare patterns ("strategy vs state?")
- The user wants existing code refactored toward a pattern
Workflow
- Identify the pattern(s) from the user's question using the catalog below.
- Read the reference file at
references/<pattern>.mdfor the explanation, applicability, trade-offs, and related patterns. - Read the language example at
examples/<pattern>/<pattern>.<ext>when the user works in (or asks for) a specific language. Adapt it to their domain rather than pasting the generic example verbatim. - Answer with: what the pattern does, when to use it (and when not to), and code adapted to the user's context.
If the user's problem does not match any pattern cleanly, say so — do not force a pattern where a plain function or data structure is simpler.
Pattern Catalog
Creational
Patterns that abstract the instantiation process.
| Pattern | Intent | Reference |
|---|---|---|
| Abstract Factory | Create families of related objects without specifying concrete classes | references/abstract-factory.md |
| Builder | Construct complex objects step by step, separating construction from representation | references/builder.md |
| Factory Method | Let subclasses decide which class to instantiate | references/factory-method.md |
| Prototype | Create objects by cloning an existing instance | references/prototype.md |
| Singleton | Ensure a class has one instance with a global access point | references/singleton.md |
Structural
Patterns that compose classes and objects into larger structures.
| Pattern | Intent | Reference |
|---|---|---|
| Adapter | Convert one interface into another that clients expect | references/adapter.md |
| Bridge | Decouple an abstraction from its implementation so both can vary | references/bridge.md |
| Composite | Treat individual objects and compositions uniformly in tree structures | references/composite.md |
| Decorator | Attach responsibilities to objects dynamically without subclassing | references/decorator.md |
| Facade | Provide a simple unified interface to a complex subsystem | references/facade.md |
| Flyweight | Share fine-grained objects to support large numbers efficiently | references/flyweight.md |
| Proxy | Provide a surrogate that controls access to another object | references/proxy.md |
Behavioral
Patterns that assign responsibilities and manage communication between objects.
| Pattern | Intent | Reference |
|---|---|---|
| Chain of Responsibility | Pass a request along a chain of handlers until one handles it | references/chain-of-responsibility.md |
| Command | Encapsulate a request as an object, enabling queues and undo | references/command.md |
| Interpreter | Define a grammar and an interpreter for a small language | references/interpreter.md |
| Iterator | Access elements of a collection sequentially without exposing its internals | references/iterator.md |
| Mediator | Centralize complex communication between objects in one mediator | references/mediator.md |
| Memento | Capture and restore an object's internal state without breaking encapsulation | references/memento.md |
| Observer | Notify dependents automatically when an object's state changes | references/observer.md |
| State | Let an object change its behavior when its internal state changes | references/state.md |
| Strategy | Define interchangeable algorithms behind a common interface | references/strategy.md |
| Template Method | Define an algorithm's skeleton, deferring some steps to subclasses | references/template-method.md |
| Visitor | Add operations to an object structure without modifying its classes | references/visitor.md |
Examples
Each pattern has a folder examples/<pattern>/ with self-contained, runnable examples named <pattern>.<ext>:
| Language | File | Notes |
|---|---|---|
| Python | <pattern>.py |
|
| C | <pattern>.c |
Emulated with structs and function pointers where the pattern relies on OOP |
| C++ | <pattern>.cpp |
|
| Java | <pattern>.java |
|
| C# | <pattern>.cs |
|
| JavaScript | <pattern>.js |
|
| Rust | <pattern>.rs |
Uses traits and enums; no inheritance-based variants |
| Go | <pattern>.go |
Uses interfaces and composition; no inheritance-based variants |
| PHP | <pattern>.php |
|
| Swift | <pattern>.swift |
Design patterns are expressed idiomatically per language — not as literal Java-style class hierarchies. C emulates with structs and function pointers; Go and Rust use interfaces, traits, and composition instead of inheritance. That is why those languages appear here but are omitted from the object-oriented-programming-paradigm skill, which requires first-class classes.
A language file may be absent when a pattern does not translate meaningfully to that language or is already built in (iterators in Python, module-scope singletons in JavaScript, sync.Once idioms in Go). The pattern's reference file notes such gaps and the idiomatic alternative.
Answering Guidelines
- Prefer the language's idiomatic form over a literal GoF class diagram (e.g. closures for Strategy in JavaScript, enums for State in Rust,
sync.Oncefor Singleton in Go). - Mention trade-offs and simpler alternatives, not just the mechanics.
- When comparing patterns, read both reference files and contrast intent, not structure.
- Do not recommend Singleton, or any pattern, as a default; patterns are solutions to specific forces, not style goals.