Agent Skills: Design Patterns

Design Patterns

Classic object-oriented design patterns for building flexible, maintainable software.

When to Use This Skill

Use this skill when:

• Refactoring code with complex conditionals or tight coupling
• Designing systems that need flexibility for future changes
• Recognizing anti-patterns that a design pattern would solve
• Code reviews where design decisions need validation
• Explaining patterns to team members

Pattern Categories

Creational Patterns

Focus on object creation mechanisms:

• Factory Method - Decouple object creation from usage
• Singleton - Single global instance
• Builder - Complex object construction step-by-step
• Abstract Factory - Families of related objects

Structural Patterns

Deal with object composition:

• Decorator - Add behaviors dynamically
• Facade - Simplify complex subsystems
• Adapter - Make incompatible interfaces work together
• Proxy - Control access, caching, lazy loading

Behavioral Patterns

Address communication between objects:

• Observer - Event notification/subscription
• Strategy - Interchangeable algorithms
• Command - Encapsulate requests as objects
• State - Behavior based on internal state

Quick Reference

| Pattern | Use When | Complexity | |---------|----------|------------| | Factory Method | Creating objects without specifying exact class | Medium | | Singleton | Need single global instance | Easy | | Builder | Complex construction with many optional params | Medium | | Decorator | Adding behaviors dynamically | Medium | | Facade | Simplifying complex library/subsystem | Easy | | Adapter | Integrating incompatible interfaces | Easy | | Observer | Multiple objects need state change notifications | Medium | | Strategy | Switching algorithms at runtime | Medium | | Command | Undo/redo, queuing, scheduling operations | Medium | | State | Object behavior varies by internal state | Hard |

Pattern Selection Guide

Problem: Large constructor with many optional parameters

• Use: Builder

Problem: Need to ensure only one instance exists

• Use: Singleton

Problem: Class explosion from multiple combinations

• Use: Decorator (for behaviors) or Strategy (for algorithms)

Problem: Complex library needs simpler interface

• Use: Facade

Problem: Objects need to be notified of changes

• Use: Observer

Problem: Large if/else or switch for algorithm selection

• Use: Strategy

Problem: Behavior changes based on object state

• Use: State

Reference Files

Detailed patterns with code examples:

• references/creational.md - Factory, Singleton, Builder, Abstract Factory
• references/structural.md - Decorator, Facade, Adapter, Proxy
• references/behavioral.md - Observer, Strategy, Command, State

Key Principles

SOLID Connection

• Single Responsibility: Each pattern isolates concerns
• Open/Closed: Decorator, Strategy enable extension without modification
• Liskov Substitution: Patterns use interfaces/abstract classes
• Interface Segregation: Small, focused interfaces
• Dependency Inversion: Depend on abstractions, not concretions

When NOT to Use Patterns

• Over-engineering: Don't add patterns "just in case"
• Simple problems: If a simple solution works, use it
• Premature abstraction: Wait until you see the pattern emerge
• Pattern fever: Not every problem needs a pattern

Common Anti-Patterns to Refactor

| Anti-Pattern | Symptom | Pattern Solution | |--------------|---------|------------------| | God Object | One class does everything | Facade + smaller classes | | Spaghetti conditionals | Nested if/else for types | Strategy or State | | Hardcoded dependencies | new ConcreteClass() everywhere | Factory Method | | Copy-paste variations | Similar classes with slight differences | Template Method or Strategy | | Callback hell | Deeply nested event handlers | Observer or Command |