Design Patterns

Design Patterns (GoF) — Agent Skill

Actionable rules distilled from Design Patterns: Elements of Reusable Object-Oriented Software (Gamma, Helm, Johnson, Vlissides, 1994). Patterns capture proven designs — not clever tricks. Apply only when the flexibility is actually needed.

Pair with clean-code for implementation quality; domain-driven-design when boundaries and domain models matter.

When to apply

• Choosing how to structure classes/objects for change
• Refactoring toward loose coupling, composability, or pluggable behavior
• Integrating incompatible interfaces, hiding platform details, or extending without subclass explosion
• User says: design pattern, GoF, Strategy, Factory, Observer, Decorator, Adapter

Do not sprinkle patterns for resume-driven design. Read Consequences before applying.

Core laws (non-negotiable)

1. Program to an interface, not an implementation — clients depend on abstractions.
2. Favor object composition over class inheritance — compose behavior; don't subclass for every variant.
3. Encapsulate what varies — each pattern isolates one aspect that changes independently.
4. Delegation over inheritance — Strategy, State, Visitor delegate to helper objects.
5. Run-time structure ≠ compile-time structure — many patterns build dynamic object graphs (Composite, Decorator, Observer).
6. Patterns are not frameworks — you implement them each time; they document intent and trade-offs.
7. Only apply when needed — extra indirection has cost (complexity, performance).

Agent workflow

1. PROBLEM    — name the design force (what must vary? what causes redesign?)
2. SELECT     — match cause of redesign OR aspect to vary (Table below)
3. VALIDATE   — check Applicability + Consequences; consider simpler fix first
4. NAME       — use domain names + pattern role (e.g. TeXLayoutStrategy)
5. IMPLEMENT  — minimal structure; prefer composition
6. VERIFY     — clean-code pass; don't over-abstract

Selection order: (1) cause of redesign → (2) intent scan → (3) related patterns graph → (4) compare patterns of same purpose.

Two OOD principles (Ch 1)

Causes of redesign → patterns (Ch 1.6)

Ask: "What should be variable without redesign?" — pick pattern that encapsulates that aspect.

Pattern catalog — intents (23 patterns)

Creational — object creation

Choose creational: Factory Method = subclass parameterization. Abstract Factory / Builder / Prototype = object-composition parameterization (factory object). Prototype when classes vary at runtime or cloning is costly to subclass.

Structural — composition & interfaces

Adapter vs Bridge: Adapter fixes two existing interfaces; Bridge plans multiple implementations upfront. Adapter vs Facade: Adapter reuses old interface; Facade defines new higher-level one. Composite vs Decorator vs Proxy: Similar structure; intent differs — part-whole hierarchy vs add behavior vs control access.

Behavioral — algorithms & responsibility

Encapsulating variation: Strategy (algorithm), State (state-dependent behavior), Mediator (interaction protocol), Iterator (traversal). Chain of Responsibility = dynamic open-ended chain.

Aspects you can vary (selection table)

MVC mapping (canonical example)

Smalltalk MVC demonstrates three patterns working together:

Use this when explaining publish-subscribe UI or pluggable behavior.

Lexi case study — pattern → problem (Ch 2)

Pattern comparisons (chapter discussions)

Creational

• Factory Method — easiest start; subclass proliferation risk.
• Abstract Factory — product families; large factory hierarchies.
• Prototype — clone existing instances; hide concrete classes from clients.
• Builder — step-by-step complex assembly; separate director if needed.
• Singleton — global access; prefer DI in modern code when possible.

Structural

• Adapter — retrofit compatibility. Bridge — intentional abstraction/implementation split.
• Decorator — transparent wrapper adding behavior. Proxy — access control, not feature stacking.
• Flyweight — many similar objects; extrinsic state passed in. Identity tests may lie.

Behavioral

• Strategy vs Template Method — composition/delegation vs inheritance; Strategy varies algorithm at runtime.
• State vs Strategy — State transitions are internal; Strategy chosen by client/context.
• Command vs Strategy — Command encapsulates full request + undo; Strategy is algorithm slot.
• Observer vs Mediator — Observer broadcast; Mediator centralizes interaction rules.
• Visitor vs double dispatch — add operations without changing element classes; new element types hurt Visitor.

Modern usage notes (agent)

Functional languages: some patterns are language features (e.g. first-class functions ≈ Strategy). Still name the force being addressed.

Smells → pattern direction

First ask: Can a simpler refactor (extract function, inject dependency) suffice? YAGNI applies to patterns.

Review output format

## Design force
[What must vary or what redesign risk]

## Recommended pattern(s)
- [Name] — [one-line intent match]

## Alternatives considered
- [Pattern] — why not

## Consequences
- [Flexibility gained vs complexity/cost]

## Implementation sketch
[Domain-named roles, composition over inheritance]

Implementation checklist (before marking done)

• Pattern addresses a real cause of redesign or variation point
• Clients depend on abstractions, not concrete classes
• Composition/delegation preferred over deep inheritance
• Participant names reflect domain (Strategy suffix where helpful)
• Consequences accepted (indirection, object count, identity)
• Not over-applied — simpler design rejected for good reason
• clean-code pass on resulting structure

Source

Gamma, Helm, Johnson, Vlissides — Design Patterns (Addison-Wesley, 1994). Personal skill for agent-assisted work.