Best Software Design Patterns Every Dev Needs

Design patterns separate developers who write code that works from those who write code that lasts. When you ship a feature that becomes impossible to modify six months later, it's rarely because you lacked technical knowledge — it's because you solved the right problem with the wrong structure. The cost is real: teams spend 40-60% of development time modifying existing code, and most of that friction comes from architectural decisions made when the codebase was 10% of its current size.

This article covers the essential design patterns that solve recurring problems in production systems. You'll learn not just what each pattern is, but when it solves a real problem versus when it adds unnecessary complexity. The focus is on patterns that pay for themselves in reduced debugging time, easier feature additions, and fewer production incidents — patterns that experienced developers reach for instinctively because they've been burned by the alternatives.

We'll cover creational, structural, and behavioral patterns with code examples in JavaScript and TypeScript, along with the specific warning signs that indicate when each pattern is needed.

Why Most Developers Learn Patterns Wrong

Design patterns became popular through the Gang of Four book in 1994, but the way they're taught creates a specific problem: developers memorize pattern names and structures without understanding the pain points each pattern solves. This leads to pattern overuse — applying Observer pattern to a simple event callback, or wrapping every class instantiation in a Factory when direct construction would suffice.

The correct approach is problem-first: you should recognize the symptoms of structural problems in your code, then apply the pattern that specifically addresses those symptoms. If you're not experiencing the problem, you don't need the pattern. A Singleton that prevents accidental multiple instantiations is valuable. A Singleton that exists because "there should only be one database connection" but doesn't actually prevent you from creating multiple connections is just a complicated global variable.

Singleton Pattern: Controlled Global Access

The Singleton pattern ensures a class has exactly one instance and provides a global point of access to it. Its reputation is mixed — it's simultaneously one of the most useful and most misused patterns. The key distinction: Singletons are valuable when the single instance property is enforced by the pattern, not just documented.

When you actually need it: Configuration managers, logger instances, database connection pools where multiple instances would cause resource conflicts or state synchronization issues. The pattern prevents accidental instantiation, not just discouraged instantiation.

Code example:

class DatabaseConnection {
    private static instance: DatabaseConnection;
    private connection: any;

    private constructor() {
        // Private constructor prevents external instantiation
        this.connection = this.createConnection();
    }

    public static getInstance(): DatabaseConnection {
        if (!DatabaseConnection.instance) {
            DatabaseConnection.instance = new DatabaseConnection();
        }
        return DatabaseConnection.instance;
    }

    private createConnection() {
        // Actual connection logic
        return { connected: true };
    }

    public query(sql: string) {
        return this.connection.query(sql);
    }
}

// Usage
const db1 = DatabaseConnection.getInstance();
const db2 = DatabaseConnection.getInstance();
// db1 and db2 reference the same instance
// new DatabaseConnection() would be a compile error

The private constructor is essential — without it, you haven't actually prevented multiple instances, you've just made one instance accessible via a static method. That's not a Singleton, it's a poorly designed global variable.

Common failure mode: Using Singleton for objects that should be mockable in tests. If your Singleton wraps external services (APIs, databases), tests become difficult because you can't substitute a fake implementation. Solution: use dependency injection for external services, reserve Singleton for truly global state like configuration.

Factory Pattern: Decoupling Object Creation

Factory patterns encapsulate object creation logic, allowing you to create objects without specifying their exact class. This is useful when the creation logic is complex, varies based on runtime conditions, or when you want to decouple code from concrete implementations.

There are three common variants: Simple Factory, Factory Method, and Abstract Factory. Most codebases need only the first two. Abstract Factory solves problems that appear in plugin systems and frameworks, not typical application code.

Simple Factory example:

interface PaymentProcessor {
    processPayment(amount: number): Promise<void>;
}

class StripeProcessor implements PaymentProcessor {
    async processPayment(amount: number) {
        // Stripe-specific logic
        console.log(`Processing $${amount} via Stripe`);
    }
}

class PayPalProcessor implements PaymentProcessor {
    async processPayment(amount: number) {
        // PayPal-specific logic
        console.log(`Processing $${amount} via PayPal`);
    }
}

class PaymentProcessorFactory {
    static create(provider: string): PaymentProcessor {
        switch(provider) {
            case 'stripe':
                return new StripeProcessor();
            case 'paypal':
                return new PayPalProcessor();
            default:
                throw new Error(`Unknown provider: ${provider}`);
        }
    }
}

// Usage
const processor = PaymentProcessorFactory.create('stripe');
await processor.processPayment(100);

This Factory solves a real problem: the calling code doesn't need to know about Stripe or PayPal classes, only the PaymentProcessor interface. When you add a third payment provider, you modify the Factory and leave all calling code unchanged. Without the Factory, every piece of code that processes payments would need its own switch statement.

Observer Pattern: Event-Driven Communication

Observer defines a one-to-many dependency between objects so that when one object changes state, all its dependents are notified automatically. This is the pattern behind event emitters, pub/sub systems, and reactive programming.

The key benefit: loose coupling. Observers don't need to know about each other, and the subject doesn't need to know what observers do with the notifications. The cost: harder to trace execution flow and potential for memory leaks if observers aren't properly removed.

class EventEmitter {
    private events: Map<string, Function[]> = new Map();

    on(event: string, callback: Function) {
        if (!this.events.has(event)) {
            this.events.set(event, []);
        }
        this.events.get(event)!.push(callback);
    }

    off(event: string, callback: Function) {
        if (!this.events.has(event)) return;

        const callbacks = this.events.get(event)!;
        const index = callbacks.indexOf(callback);
        if (index > -1) {
            callbacks.splice(index, 1);
        }
    }

    emit(event: string, data?: any) {
        if (!this.events.has(event)) return;

        this.events.get(event)!.forEach(callback => {
            callback(data);
        });
    }
}

// Usage
class User extends EventEmitter {
    private name: string;

    constructor(name: string) {
        super();
        this.name = name;
    }

    updateProfile(newName: string) {
        const oldName = this.name;
        this.name = newName;
        this.emit('profile:updated', { oldName, newName });
    }
}

const user = new User('Alice');

user.on('profile:updated', (data) => {
    console.log(`Profile changed from ${data.oldName} to ${data.newName}`);
});

user.on('profile:updated', (data) => {
    // Send analytics event
    console.log('Analytics: profile update');
});

user.updateProfile('Alice Smith'); // Both listeners fire

When Observer creates problems: When event chains become long and conditional. If Event A triggers Event B which conditionally triggers Event C, debugging becomes difficult because there's no single code path to trace. This is when you should consider replacing Observer with a more explicit pattern like Command or State.

Strategy Pattern: Swappable Algorithms

Strategy encapsulates algorithms inside classes and makes them interchangeable. The calling code depends on an interface, not a concrete implementation, so you can swap algorithms at runtime without changing the code that uses them.

This pattern is particularly useful for avoiding large conditional statements where each branch implements a variant of the same behavior. Instead of if/else or switch statements that grow every time you add a new variant, you create a new strategy class.

interface SortStrategy {
    sort(data: number[]): number[];
}

class QuickSort implements SortStrategy {
    sort(data: number[]): number[] {
        if (data.length <= 1) return data;
        // QuickSort implementation
        const pivot = data[0];
        const left = data.slice(1).filter(x => x < pivot);
        const right = data.slice(1).filter(x => x >= pivot);
        return [...this.sort(left), pivot, ...this.sort(right)];
    }
}

class MergeSort implements SortStrategy {
    sort(data: number[]): number[] {
        if (data.length <= 1) return data;
        // MergeSort implementation
        const mid = Math.floor(data.length / 2);
        const left = this.sort(data.slice(0, mid));
        const right = this.sort(data.slice(mid));
        return this.merge(left, right);
    }

    private merge(left: number[], right: number[]): number[] {
        const result: number[] = [];
        let i = 0, j = 0;
        while (i < left.length && j < right.length) {
            if (left[i] < right[j]) {
                result.push(left[i++]);
            } else {
                result.push(right[j++]);
            }
        }
        return result.concat(left.slice(i)).concat(right.slice(j));
    }
}

class DataSorter {
    constructor(private strategy: SortStrategy) {}

    setStrategy(strategy: SortStrategy) {
        this.strategy = strategy;
    }

    sort(data: number[]): number[] {
        return this.strategy.sort(data);
    }
}

// Usage
const data = [5, 2, 9, 1, 7];
const sorter = new DataSorter(new QuickSort());
console.log(sorter.sort(data));

// Change strategy at runtime
sorter.setStrategy(new MergeSort());
console.log(sorter.sort(data));

The alternative without Strategy would be a DataSorter class with a sort method containing a large switch statement. Every time you add a new algorithm, you modify that switch statement. With Strategy, you add a new class and leave existing code unchanged. This adheres to the Open/Closed Principle: open for extension, closed for modification.

Decorator Pattern: Adding Behavior Without Modification

Decorator attaches additional responsibilities to an object dynamically. It provides a flexible alternative to subclassing for extending functionality. You wrap an object with another object that adds behavior, and you can stack multiple decorators to combine behaviors.

This is particularly useful when you have a core class and multiple optional features that can be combined in various ways. Creating a subclass for every combination would result in a class explosion.

interface Coffee {
    cost(): number;
    description(): string;
}

class SimpleCoffee implements Coffee {
    cost(): number {
        return 2;
    }

    description(): string {
        return 'Simple coffee';
    }
}

// Decorator base
abstract class CoffeeDecorator implements Coffee {
    constructor(protected coffee: Coffee) {}

    abstract cost(): number;
    abstract description(): string;
}

class MilkDecorator extends CoffeeDecorator {
    cost(): number {
        return this.coffee.cost() + 0.5;
    }

    description(): string {
        return this.coffee.description() + ', milk';
    }
}

class SugarDecorator extends CoffeeDecorator {
    cost(): number {
        return this.coffee.cost() + 0.3;
    }

    description(): string {
        return this.coffee.description() + ', sugar';
    }
}

class WhipDecorator extends CoffeeDecorator {
    cost(): number {
        return this.coffee.cost() + 0.7;
    }

    description(): string {
        return this.coffee.description() + ', whip';
    }
}

// Usage
let coffee: Coffee = new SimpleCoffee();
console.log(`${coffee.description()}: $${coffee.cost()}`);

coffee = new MilkDecorator(coffee);
coffee = new SugarDecorator(coffee);
coffee = new WhipDecorator(coffee);
console.log(`${coffee.description()}: $${coffee.cost()}`);
// Output: "Simple coffee, milk, sugar, whip: $3.5"

Without Decorator, you'd need classes like CoffeeWithMilk, CoffeeWithMilkAndSugar, CoffeeWithMilkAndWhip, etc. With three decorators, that's 8 combinations. With five decorators, it's 32 combinations. Decorator reduces that to 6 classes (1 base + 5 decorators) that can be combined flexibly.

Adapter Pattern: Interface Translation

Adapter converts the interface of a class into another interface clients expect. It's useful when integrating third-party libraries or legacy code that doesn't match your application's interface conventions. Rather than modifying existing code to match external interfaces, you create an adapter that translates between them.

// Your application expects this interface
interface Logger {
    info(message: string): void;
    error(message: string): void;
}

// Third-party library has this interface
class ThirdPartyLogger {
    log(level: string, message: string) {
        console.log(`[${level}] ${message}`);
    }
}

// Adapter makes the third-party logger compatible
class LoggerAdapter implements Logger {
    constructor(private thirdPartyLogger: ThirdPartyLogger) {}

    info(message: string): void {
        this.thirdPartyLogger.log('INFO', message);
    }

    error(message: string): void {
        this.thirdPartyLogger.log('ERROR', message);
    }
}

// Usage
const thirdPartyLogger = new ThirdPartyLogger();
const logger: Logger = new LoggerAdapter(thirdPartyLogger);

logger.info('Application started');
logger.error('Something went wrong');

Adapter is particularly valuable when you might need to swap implementations. In this example, if you later want to replace ThirdPartyLogger with a different logging service, you create a new adapter and change one line of code. All code that depends on the Logger interface continues working without modification.

Command Pattern: Encapsulating Actions

Command encapsulates a request as an object, allowing you to parameterize clients with different requests, queue requests, log requests, and support undo operations. This pattern is essential for implementing undo/redo functionality, job queues, and transaction systems.

interface Command {
    execute(): void;
    undo(): void;
}

class Document {
    private content: string = '';

    addText(text: string) {
        this.content += text;
    }

    removeText(length: number) {
        this.content = this.content.slice(0, -length);
    }

    getContent(): string {
        return this.content;
    }
}

class AddTextCommand implements Command {
    constructor(
        private document: Document,
        private text: string
    ) {}

    execute(): void {
        this.document.addText(this.text);
    }

    undo(): void {
        this.document.removeText(this.text.length);
    }
}

class CommandHistory {
    private history: Command[] = [];
    private current: number = -1;

    execute(command: Command) {
        // Remove any commands after current position
        this.history = this.history.slice(0, this.current + 1);

        command.execute();
        this.history.push(command);
        this.current++;
    }

    undo() {
        if (this.current < 0) return;

        this.history[this.current].undo();
        this.current--;
    }

    redo() {
        if (this.current >= this.history.length - 1) return;

        this.current++;
        this.history[this.current].execute();
    }
}

// Usage
const doc = new Document();
const history = new CommandHistory();

history.execute(new AddTextCommand(doc, 'Hello '));
history.execute(new AddTextCommand(doc, 'World'));
console.log(doc.getContent()); // "Hello World"

history.undo();
console.log(doc.getContent()); // "Hello "

history.redo();
console.log(doc.getContent()); // "Hello World"

The Command pattern's power comes from treating operations as first-class objects. You can store them, pass them as parameters, and manipulate them. This is how text editors implement undo/redo, how job queues work, and how transactional systems maintain operation logs.

Template Method Pattern: Algorithm Skeleton

Template Method defines the skeleton of an algorithm in a base class, allowing subclasses to override specific steps without changing the algorithm's structure. This is useful when you have multiple implementations that follow the same general process but differ in specific details.

abstract class DataProcessor {
    // Template method
    public process(): void {
        const data = this.loadData();
        const validated = this.validate(data);
        const transformed = this.transform(validated);
        this.save(transformed);
    }

    // Steps to be implemented by subclasses
    protected abstract loadData(): any;
    protected abstract validate(data: any): any;
    protected abstract transform(data: any): any;
    protected abstract save(data: any): void;
}

class CSVProcessor extends DataProcessor {
    protected loadData(): any {
        console.log('Loading CSV file');
        return 'csv data';
    }

    protected validate(data: any): any {
        console.log('Validating CSV data');
        return data;
    }

    protected transform(data: any): any {
        console.log('Transforming CSV to JSON');
        return { csv: data };
    }

    protected save(data: any): void {
        console.log('Saving to database:', data);
    }
}

class XMLProcessor extends DataProcessor {
    protected loadData(): any {
        console.log('Loading XML file');
        return 'data';
    }

    protected validate(data: any): any {
        console.log('Validating XML data');
        return data;
    }

    protected transform(data: any): any {
        console.log('Transforming XML to JSON');
        return { xml: data };
    }

    protected save(data: any): void {
        console.log('Saving to database:', data);
    }
}

// Usage
const csvProcessor = new CSVProcessor();
csvProcessor.process();

const xmlProcessor = new XMLProcessor();
xmlProcessor.process();

Template Method enforces a consistent process across different implementations. Both CSV and XML processors follow the same load-validate-transform-save sequence. This pattern prevents developers from accidentally skipping validation or saving data in the wrong order.

Builder Pattern: Complex Object Construction

Builder separates the construction of a complex object from its representation, allowing the same construction process to create different representations. This is particularly useful for objects with many optional parameters or configuration options.

class HttpRequest {
    public url: string = '';
    public method: string = 'GET';
    public headers: Record<string, string> = {};
    public body?: any;
    public timeout: number = 30000;
    public retries: number = 0;
}

class HttpRequestBuilder {
    private request: HttpRequest;

    constructor() {
        this.request = new HttpRequest();
    }

    setUrl(url: string): HttpRequestBuilder {
        this.request.url = url;
        return this;
    }

    setMethod(method: string): HttpRequestBuilder {
        this.request.method = method;
        return this;
    }

    addHeader(key: string, value: string): HttpRequestBuilder {
        this.request.headers[key] = value;
        return this;
    }

    setBody(body: any): HttpRequestBuilder {
        this.request.body = body;
        return this;
    }

    setTimeout(timeout: number): HttpRequestBuilder {
        this.request.timeout = timeout;
        return this;
    }

    setRetries(retries: number): HttpRequestBuilder {
        this.request.retries = retries;
        return this;
    }

    build(): HttpRequest {
        if (!this.request.url) {
            throw new Error('URL is required');
        }
        return this.request;
    }
}

// Usage
const request = new HttpRequestBuilder()
    .setUrl('https://api.example.com/users')
    .setMethod('POST')
    .addHeader('Content-Type', 'application/json')
    .addHeader('Authorization', 'Bearer token')
    .setBody({ name: 'John' })
    .setTimeout(5000)
    .setRetries(3)
    .build();

Without Builder, you'd need either a constructor with many parameters (error-prone and hard to read) or multiple setter calls without fluent chaining (verbose). Builder provides a clean, readable way to construct complex objects and enforces required fields at build time.

State Pattern: Object Behavior Based on State

State allows an object to alter its behavior when its internal state changes. The object will appear to change its class. This pattern is useful when an object's behavior varies significantly based on its state and you have large conditional statements that depend on the object's state.

interface ConnectionState {
    connect(connection: Connection): void;
    disconnect(connection: Connection): void;
    sendData(connection: Connection, data: string): void;
}

class DisconnectedState implements ConnectionState {
    connect(connection: Connection): void {
        console.log('Connecting...');
        connection.setState(new ConnectingState());
    }

    disconnect(connection: Connection): void {
        console.log('Already disconnected');
    }

    sendData(connection: Connection, data: string): void {
        console.log('Cannot send data: not connected');
    }
}

class ConnectingState implements ConnectionState {
    connect(connection: Connection): void {
        console.log('Already connecting');
    }

    disconnect(connection: Connection): void {
        console.log('Cancelling connection');
        connection.setState(new DisconnectedState());
    }

    sendData(connection: Connection, data: string): void {
        console.log('Cannot send data: still connecting');
    }
}

class ConnectedState implements ConnectionState {
    connect(connection: Connection): void {
        console.log('Already connected');
    }

    disconnect(connection: Connection): void {
        console.log('Disconnecting...');
        connection.setState(new DisconnectedState());
    }

    sendData(connection: Connection, data: string): void {
        console.log(`Sending data: ${data}`);
    }
}

class Connection {
    private state: ConnectionState;

    constructor() {
        this.state = new DisconnectedState();
    }

    setState(state: ConnectionState): void {
        this.state = state;
    }

    connect(): void {
        this.state.connect(this);
    }

    disconnect(): void {
        this.state.disconnect(this);
    }

    sendData(data: string): void {
        this.state.sendData(this, data);
    }
}

// Usage
const connection = new Connection();
connection.sendData('Hello'); // "Cannot send data: not connected"
connection.connect(); // "Connecting..."
connection.sendData('Hello'); // "Cannot send data: still connecting"
connection.setState(new ConnectedState()); // Simulate connection success
connection.sendData('Hello'); // "Sending data: Hello"
connection.disconnect(); // "Disconnecting..."

The alternative without State would be a Connection class with methods full of if/else statements checking the current state. Every method would need the same state checks, and adding a new state would require modifying every method. With State pattern, each state's behavior is encapsulated in its own class.

When Patterns Create More Problems Than They Solve

Design patterns can become anti-patterns when applied incorrectly. The most common mistakes:

Premature abstraction: Implementing Factory pattern when you have one concrete class "because we might add more later." Wait until you actually have multiple implementations. The cost of refactoring later is usually lower than maintaining unnecessary abstraction now.

Pattern stacking: Combining multiple patterns for a simple problem. A Factory that returns a Builder that creates Decorators might be architecturally interesting, but it's maintenance hell unless each pattern solves a specific problem you're actually experiencing.

Forcing patterns onto inappropriate problems: Using Singleton for objects that should have limited scope, or Observer for simple callbacks that don't need decoupling. Patterns are tools, not requirements.

Ignoring language features: Some patterns exist to work around limitations in languages like C++ or Java. JavaScript's first-class functions eliminate the need for many behavioral patterns. TypeScript's union types can replace some uses of State pattern. Use the pattern when it's the clearest solution, not when it's the textbook solution.

Patterns in Modern JavaScript and TypeScript

Some patterns have evolved or become less relevant in modern JavaScript/TypeScript. Understanding these adaptations prevents you from implementing patterns in outdated ways.

Module pattern evolution: The classic Module pattern used IIFEs (Immediately Invoked Function Expressions) to create private scope. ES6 modules made this obsolete. If you're still using IIFEs for encapsulation in new code, you're fighting the language instead of using it.

Promises as a pattern implementation: Promises are essentially a built-in implementation of Observer pattern for asynchronous operations. Understanding this helps you see when custom Observer implementations are unnecessary — if you're implementing Observer purely for async operations, you might just need Promises or async/await.

Proxy pattern as a language feature: JavaScript's Proxy object is literally the Proxy pattern as a first-class language feature. This enables patterns like lazy initialization and access control without writing full proxy classes:

const handler = {
    get(target: any, property: string) {
        console.log(`Accessing property: ${property}`);
        return target[property];
    },
    set(target: any, property: string, value: any) {
        console.log(`Setting ${property} to ${value}`);
        target[property] = value;
        return true;
    }
};

const user = new Proxy({ name: 'Alice' }, handler);
console.log(user.name); // Logs "Accessing property: name", returns "Alice"
user.name = 'Bob'; // Logs "Setting name to Bob"

Recognizing When You Need a Pattern

The best developers don't start with patterns — they start with working code and refactor to patterns when pain points emerge. Here are the warning signs:

For Singleton: You keep accidentally creating multiple instances and getting state conflicts. Constructor parameters make debugging difficult because you need to trace back to where an instance was created.

For Factory: You have conditional logic for object creation duplicated in multiple places. Adding a new type requires changing code in 3+ locations.

For Observer: You're passing callback functions through multiple layers of your application just to notify distant components. Components are tightly coupled because they need direct references to call methods on each other.

For Strategy: You have a method with a large switch statement or if/else chain, and each branch implements a variation of the same behavior. Adding a new variation requires modifying that central method.

For State: You have multiple methods with the same state checks, and the state checks are getting complicated. The state transitions themselves need to be controlled and validated.

If you're not experiencing these specific pain points, you don't need these patterns yet. Write the simplest code that works, and let patterns emerge when complexity demands them.

FAQ

How many design patterns should I know to be an effective developer?

You should deeply understand 6-8 patterns that solve problems you encounter regularly. For most web developers, that's Singleton, Factory, Observer, Strategy, Decorator, and Adapter. Template Method and Builder become important as you work with more complex systems. Knowing all 23 Gang of Four patterns is less valuable than deeply understanding when and why to use the ones you actually need. Recognition is more important than memorization — you should be able to identify when a problem would benefit from a pattern you've seen, even if you need to look up implementation details.

Are design patterns still relevant with modern frameworks like React?

Yes, but they manifest differently. React's hooks are essentially Strategy pattern — useEffect lets you inject different side-effect behaviors. Higher-order components are Decorator pattern. Context API is Observer pattern. The patterns are there, but the framework provides implementations. Understanding the underlying patterns helps you use these features more effectively and recognize when you need custom implementations for problems the framework doesn't solve. Patterns are about recognizing problem structures, and those structures don't disappear just because you're using a framework.

Should I use inheritance-based or composition-based patterns?

Prefer composition in most cases. Modern JavaScript/TypeScript development favors composition because it's more flexible and avoids fragile base class problems. Patterns like Decorator and Strategy work better with composition. The main exception is Template Method, which requires inheritance to work. If you find yourself creating deep inheritance hierarchies to implement a pattern, you're probably forcing an inheritance-based solution onto a problem that would be clearer with composition.

How do I convince my team to use design patterns without over-engineering?

Don't start by advocating for patterns — start by identifying specific pain points in your codebase. When you find duplicated object creation logic, propose Factory as a solution to that specific problem. When state management becomes tangled, demonstrate State pattern as a refactoring. Introduce patterns as solutions to problems the team already recognizes, not as abstract best practices. If the team doesn't see the problem, they won't value the solution.

What's the difference between a design pattern and just good code organization?

Design patterns are formalized solutions to recurring problems that have proven effective across many codebases. Good code organization is broader and includes patterns plus other practices like meaningful naming, clear function boundaries, and logical file structure. A pattern becomes relevant when you encounter the specific problem it solves. Good organization is always relevant. You can have well-organized code without using any named patterns, but you can't effectively use patterns without good organization.

How do I know if I'm overusing design patterns?

Warning signs: your code has more abstraction layers than business logic, new team members can't understand the code without studying pattern theory, simple feature additions require changes to multiple pattern implementations, or you're using patterns "because we might need flexibility later" rather than to solve current problems. The test: if you removed the pattern and wrote straightforward procedural code, would it actually be simpler? If yes, you're over-engineering.

Should I learn design patterns from the Gang of Four book or modern resources?

Start with modern resources that show patterns in JavaScript/TypeScript. The Gang of Four book is valuable for deep understanding but uses C++ and Java examples that don't translate directly to modern web development. Learn the problems patterns solve and the trade-offs they involve, not just the UML diagrams. Once you understand patterns in your working language, the Gang of Four book provides valuable historical context and deeper theoretical foundation.

How do design patterns relate to SOLID principles?

Patterns are concrete implementations; SOLID principles are abstract guidelines. Many patterns embody specific SOLID principles. Strategy and State support Open/Closed (open for extension, closed for modification). Adapter supports Interface Segregation (don't depend on interfaces you don't use). Factory supports Dependency Inversion (depend on abstractions, not concretions). Understanding SOLID helps you recognize when a pattern is appropriate, but patterns give you concrete code structures to implement SOLID in practice.

Can I mix multiple patterns in a single implementation?

Yes, but each pattern should solve a distinct problem. A Factory that creates Strategies makes sense because Factory solves the creation problem and Strategy solves the algorithm variation problem. But if you're combining patterns just to demonstrate architectural knowledge, you're over-engineering. The combination should feel necessary, not impressive. If explaining why you need the combination takes more than two sentences, you probably don't need it.

How do I refactor existing code to use patterns without breaking everything?

Start small and incremental. Identify one pain point, introduce the pattern that solves it, and ensure everything still works before moving to the next refactoring. Write tests before refactoring so you can verify behavior doesn't change. Don't try to refactor an entire codebase to use patterns all at once — that's a recipe for introducing bugs. Patterns should make code easier to change, so if the refactoring is risky and difficult, you might be applying the wrong pattern or solving the wrong problem.

What's the best way to learn design patterns beyond reading about them?

Recognize them in code you already use. Find the Observer pattern in your event handling code. Identify Factory pattern in libraries you depend on. Seeing patterns in production code — especially code you already understand — makes them concrete instead of abstract. Then practice by refactoring small parts of your own projects when you encounter the problems patterns solve. Don't build practice projects just to demonstrate patterns. Refactor real code with real problems.

Conclusion

Design patterns are valuable when they solve specific problems you're experiencing, not as architectural goals in themselves. The patterns covered here — Singleton, Factory, Observer, Strategy, Decorator, Adapter, Command, Template Method, Builder, and State — handle the majority of recurring design problems in web development. The key is recognizing when you actually need them.

Start with simple, working code. Let patterns emerge when complexity demands them. A 200-line file with straightforward logic is better than a 400-line implementation spanning five patterns if the simpler version solves your problem. Patterns earn their place by reducing debugging time, simplifying feature additions, and preventing production incidents — not by making your architecture look impressive.

The mark of a developer who understands patterns isn't how many they can name, but how reliably they recognize when each pattern solves a real problem better than any alternative. That recognition comes from experience, not memorization.