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 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