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

Problem Pattern Use When

Single instance needed Singleton Global state, resource management

Complex object creation Builder Many optional parameters

Family of related objects Abstract Factory Need consistent object families

Clone existing objects Prototype Object creation is expensive

Interface mismatch Adapter Integrating legacy code

Add responsibilities Decorator Need flexible extensions

Simplify complex system Facade Need simplified interface

Control access Proxy Lazy loading, access control

Interchangeable algorithms Strategy Multiple algorithm variants

Notify dependents Observer Event handling, pub-sub

Encapsulate requests Command Undo/redo, queuing operations

State-dependent behavior State Complex state transitions

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.