gof-design-patterns

Skill: gof-design-patterns

23 Gang of Four patterns as a decision guide. Identify the symptom or goal, pick the pattern, then read its reference file for the structural recipe.

---

Pick by Symptom

Code Smell	Pattern(s)
if/else or switch on object type	Strategy, Visitor
if/else or switch on object state	State
Telescoping constructors	Builder
Subclass explosion for feature combinations	Decorator, Strategy, Bridge
new ConcreteClass() scattered throughout codebase	Factory Method, Abstract Factory
Hard-coded class names	Factory Method, Prototype
Subsystem complexity leaking into client code	Facade
Complex many-to-many object communication	Mediator
Manual state propagation to multiple dependents	Observer
Duplicated algorithm structure across subclasses	Template Method
Large conditional routing requests to handlers	Chain of Responsibility
High memory cost from many fine-grained objects	Flyweight

---

Pick by Goal

What you want	Pattern
Hide how objects are created	Factory Method, Abstract Factory, Builder, Prototype
Ensure exactly one instance globally	Singleton
Make incompatible interfaces work together	Adapter
Decouple abstraction from implementation	Bridge
Treat individual objects and groups uniformly	Composite
Add behavior dynamically without subclassing	Decorator
Simplify a complex subsystem API	Facade
Lazy-load, cache, or control access to an object	Proxy
Make requests undoable, queueable, or loggable	Command (+ Memento for undo state)
Traverse a collection without exposing internals	Iterator
Encapsulate an interchangeable algorithm	Strategy
Change behavior when internal state changes	State
Notify dependents automatically on state change	Observer
Add operations to a stable object structure	Visitor

---

Choosing Between Similar Patterns

Choosing between	Key distinction
Strategy vs Template Method	Composition (delegate whole algorithm) vs inheritance (override steps)
State vs Strategy	State transitions itself; Strategy is chosen by the client
Adapter vs Facade	Adapting a single class vs simplifying an entire subsystem
Decorator vs Proxy	Adding behavior vs controlling access
Factory Method vs Abstract Factory	Single product type vs product families
Command vs Chain of Responsibility	Encapsulate and invoke an action vs route a request to a handler

---

Pattern Categories

Creational (5) — control what gets created and how

Abstract Factory · Builder · Factory Method · Prototype · Singleton

Structural (7) — compose classes and objects into larger structures

Adapter · Bridge · Composite · Decorator · Facade · Flyweight · Proxy

Behavioral (11) — define communication and responsibility between objects

Chain of Responsibility · Command · Interpreter · Iterator · Mediator · Memento · Observer · State · Strategy · Template Method · Visitor

---

When NOT to Apply a Pattern

Every pattern adds indirection. Apply one only when:

1. The problem is genuinely recurring — not a one-off edge case
2. The flexibility the pattern provides outweighs the extra classes and interfaces
3. Your team can maintain the added indirection

"If a straightforward solution works, use it." — GoF

---

Reference Files

Each pattern has a full file in ${CLAUDE_SKILL_DIR}/references/:

• foundations.md — GoF principles (program to interface, favor composition, encapsulate what varies)
• techniques.md — master table, pattern relationships, alternative-pattern decision guide
• gof-<pattern-name>.md — structure, participants, when to use, consequences, example

Read the relevant pattern file when implementing. This SKILL.md is for selection; the reference files are for execution.