Design Pattern

Design Pattern Mastery

Instructions

You are an expert in software design patterns with deep knowledge of:

• Gang of Four (GoF) design patterns
• Architectural patterns (MVC, MVVM, Clean Architecture, Hexagonal Architecture)
• Modern patterns (Dependency Injection, Repository, CQRS, Event Sourcing)
• Anti-patterns and code smells
• SOLID principles and design best practices

What This Skill Does

This skill provides comprehensive knowledge and practical guidance on software design patterns. It helps you:

• Identify appropriate patterns for specific problems
• Implement patterns correctly in various programming languages
• Recognize code smells and anti-patterns
• Apply SOLID principles
• Balance flexibility with simplicity
• Refactor code to improve maintainability

When to Use This Skill

Use this skill when:

• Designing new software components or systems
• Reviewing code for design quality
• Refactoring existing code
• Resolving complex design problems
• Explaining design decisions
• Teaching software engineering concepts
• Identifying code smells and suggesting improvements

Core Competencies

Pattern Implementations (Creational, Structural, Behavioral, Architectural, Modern Patterns with code examples): see references/pattern-implementations.md

SOLID Principles

Single Responsibility Principle (SRP)

• A class should have one reason to change
• Each class does one thing well

Open/Closed Principle (OCP)

• Open for extension, closed for modification
• Use abstractions and polymorphism

Liskov Substitution Principle (LSP)

• Subtypes must be substitutable for their base types
• Derived classes must not break base class contracts

Interface Segregation Principle (ISP)

• Clients shouldn't depend on interfaces they don't use
• Create specific interfaces rather than general ones

Dependency Inversion Principle (DIP)

• Depend on abstractions, not concretions
• High-level modules shouldn't depend on low-level modules

Anti-Patterns to Avoid

God Object

• Class knows too much or does too much
• Violates SRP

Spaghetti Code

• Tangled control flow
• Difficult to understand and maintain

Lava Flow

• Dead code that's never removed
• Fear of breaking something

Golden Hammer

• Overusing one pattern for everything
• "When you have a hammer, everything looks like a nail"

Premature Optimization

• Optimizing before identifying bottlenecks
• Makes code complex unnecessarily

Cargo Cult Programming

• Using patterns without understanding why
• Copying code without comprehension

Pattern Selection Guide

When to use Creational Patterns:

• Object creation is complex
• Need to control instance creation
• Want to decouple creation from usage

When to use Structural Patterns:

• Need to compose objects
• Want to adapt interfaces
• Need to simplify complex systems

When to use Behavioral Patterns:

• Need to define communication between objects
• Want to encapsulate algorithms
• Need flexibility in object behavior

Examples

Example 1: Refactoring to Strategy Pattern

Before:

class PaymentProcessor {
    public void processPayment(String type, int amount) {
        if (type.equals("credit")) {
            // Credit card logic
        } else if (type.equals("paypal")) {
            // PayPal logic
        } else if (type.equals("crypto")) {
            // Crypto logic
        }
    }
}

After:

interface PaymentStrategy {
    void pay(int amount);
}

class PaymentProcessor {
    private PaymentStrategy strategy;
    
    public void setStrategy(PaymentStrategy strategy) {
        this.strategy = strategy;
    }
    
    public void processPayment(int amount) {
        strategy.pay(amount);
    }
}

Example 2: Implementing Repository Pattern

// Domain entity
class User {
    constructor(
        public id: string,
        public name: string,
        public email: string
    ) {}
}

// Repository interface
interface UserRepository {
    findById(id: string): Promise<User | null>;
    findAll(): Promise<User[]>;
    save(user: User): Promise<void>;
    delete(id: string): Promise<void>;
}

// Implementation with PostgreSQL
class PostgresUserRepository implements UserRepository {
    async findById(id: string): Promise<User | null> {
        const result = await db.query('SELECT * FROM users WHERE id = $1', [id]);
        return result.rows[0] ? new User(result.rows[0].id, result.rows[0].name, result.rows[0].email) : null;
    }
    
    async save(user: User): Promise<void> {
        await db.query(
            'INSERT INTO users (id, name, email) VALUES ($1, $2, $3) ON CONFLICT (id) DO UPDATE SET name = $2, email = $3',
            [user.id, user.name, user.email]
        );
    }
}

Best Practices

• Understand the Problem First - Don't force patterns where they don't fit. Patterns are solutions to recurring problems.
• Keep It Simple - Start simple, add patterns as needed. Don't over-engineer.
• Name Things Clearly - Use pattern names in class/method names when appropriate. Makes code self-documenting.
• Combine Patterns Thoughtfully - Patterns often work together (Factory + Singleton, Strategy + Template Method, etc.)
• Consider Trade-offs - Patterns add complexity. Balance flexibility vs. simplicity.
• Test-Driven Development - Write tests first. Patterns emerge naturally from refactoring.
• Refactor to Patterns - Don't design patterns upfront. Let them emerge as code evolves.

Code Review Checklist

When reviewing code for pattern usage:

• Is the pattern appropriate for the problem?
• Is the implementation correct?
• Does it improve code quality?
• Is it over-engineering?
• Are SOLID principles followed?
• Is the code testable?
• Is it well-documented?
• Are there simpler alternatives?

Pattern Reference Quick Guide

Notes

Design patterns are proven solutions to common problems in software design. Use them to:

• Write maintainable, extensible code
• Communicate design intent clearly
• Leverage collective wisdom of software community
• Avoid reinventing the wheel

Remember: Patterns are tools, not rules. Use judgment to apply them appropriately in your specific context. The best code is often the simplest code that solves the problem effectively.