Design Patterns: The Universal Language Every Developer Should Speak

# programming# webdev# java# typescript

jesus manrique

What design patterns are, why they matter more than ever, and real Java + TypeScript examples: Singleton, Strategy, and Observer explained with zero academic fluff.

The first time I read about design patterns was in a scanned PDF of the Gang of Four book. I lasted 15 pages before closing it. Too much theory. Too much UML. Too much "when am I ever going to use this?"

Fast forward 8 years. Today I read that same book differently. I've lived the pains those patterns solve. I've written the coupled code that Strategy decouples, the 3,000-line class that Observer breaks apart, the infinite switch statement that Factory Method eliminates.

Design patterns aren't learned by reading — they're learned by suffering. But if this article saves you even one headache, it was worth writing.

What Is a Design Pattern?

The formal definition says a design pattern is a proven solution to a recurring problem in software design. Sounds corporate. In plain English: it's an elegant trick someone else already discovered, tested, and documented so you don't have to reinvent it at 2 AM.

They're not libraries. They're not copy-paste code. They're more like blueprints: you understand the idea, adapt it to your context, and implement it in your language.

Think of it this way: architects don't design every building from scratch. They have proven solutions for things like "how to light an interior hallway" or "how to drain a flat roof." Design patterns are that, but for software.

Why Should You Care?

1. They Give You Vocabulary

Imagine this conversation without patterns:

—"Hey, I need you to create a class for the database connection that doesn't let anyone call new from outside, has a static method that always returns the same instance checking if it already exists, and stores that instance in a private field so the entire system uses exactly the same object."

With patterns:

—"Use a Singleton for the DB connection."

Three words. The speaker didn't have to explain the structure. The listener didn't need a diagram. Both immediately visualize the same solution.

Design patterns are the software equivalent of what a "C major chord" is to musicians. You don't say "put your index finger on the first fret of the second string, your middle finger on..." — you say "C major" and everyone knows what to play.

That shared vocabulary is what lets a team of 5 developers discuss a complex architecture in 20 minutes instead of 3 hours. And it's what makes you understand 60% of a class's design when you read "uses Observer" in a README before even opening the file.

2. They're Déjà Vu Solutions

90% of the design problems you face were already lived by someone in 1994. Those problems are so well-studied that the solutions have names, examples, documented trade-offs, and entire books dedicated to each one.

3. They Make You a Better Code Reviewer

Knowing patterns doesn't just help you write better — it helps you READ better. When you open someone else's codebase and recognize an Observer in the event system, a Factory in the DI container, or a Decorator in the middleware, you understand the architecture instantly. You stop reading line by line and start seeing the shape of the code.

4. They're the Bridge from Junior to Senior

There are many differences between a junior and a senior, but one of the most noticeable is this: a junior solves a problem thinking about the immediate present. A senior recognizes the shape of the problem, recalls which pattern solves it, and applies it knowing how it will scale in 6 months. Patterns are experience shortcuts.

The 3 Big Groups

The 23 classic Gang of Four patterns are grouped into three families based on their purpose:

Creational Patterns (5)

Factory Method, Abstract Factory, Builder, Prototype, Singleton

They answer one question: how do I create objects without coupling to concrete classes? They encapsulate instantiation logic so your code depends on interfaces, not new ConcreteClass().

Structural Patterns (7)

Adapter, Bridge, Composite, Decorator, Facade, Flyweight, Proxy

They answer: how do I assemble objects and classes while maintaining flexibility? They help you compose pieces without everything exploding when you add a new one.

Behavioral Patterns (11)

Chain of Responsibility, Command, Iterator, Mediator, Memento, Observer, State, Strategy, Template Method, Visitor

They answer: how do I organize communication and responsibilities between objects? These are the ones you'll use most day to day.

Real Examples in Java and TypeScript

I'm not going to explain all 23. That would be a book. I'll show you the 3 that appear most often in production, with code you can actually run.

1. Singleton — One Instance, One Global Access Point

When to use it: When you need exactly one instance of a class. Database connections, global configs, logging systems, caches.

Java:

public class DatabaseConnection {
    // volatile for visibility between threads
    private static volatile DatabaseConnection instance;
    private final String connectionString;

    // Private constructor — nobody can call new
    private DatabaseConnection() {
        this.connectionString = "jdbc:postgresql://localhost:5432/mydb";
        System.out.println("🔌 Connecting to " + connectionString);
    }

    // Double-checked locking for thread safety without synchronized overhead every time
    public static DatabaseConnection getInstance() {
        if (instance == null) {
            synchronized (DatabaseConnection.class) {
                if (instance == null) {
                    instance = new DatabaseConnection();
                }
            }
        }
        return instance;
    }

    public void query(String sql) {
        System.out.println("⚡ Executing: " + sql);
    }
}

// Usage
DatabaseConnection db1 = DatabaseConnection.getInstance();
DatabaseConnection db2 = DatabaseConnection.getInstance();
System.out.println(db1 == db2); // true — same instance

TypeScript:

class ConfigManager {
    private static instance: ConfigManager;
    private config: Record<string, string> = {};

    private constructor() {
        this.config = {
            apiUrl: "https://api.guayoyo.tech",
            maxRetries: "3",
        };
        console.log("⚙️  Configuration loaded");
    }

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

    get(key: string): string | undefined {
        return this.config[key];
    }

    set(key: string, value: string): void {
        this.config[key] = value;
    }
}

// Usage
const config1 = ConfigManager.getInstance();
const config2 = ConfigManager.getInstance();
console.log(config1 === config2);      // true
console.log(config1.get("apiUrl"));    // "https://api.guayoyo.tech"

⚠️ When NOT to use it: Singleton is the most abused pattern. Don't use it for everything. If your class has mutable state that changes over time, a Singleton can be a headache in testing and multi-threaded applications. Use it when you truly need ONE and only ONE instance.

2. Strategy — Interchangeable Algorithms

When to use it: When you have multiple ways of doing something and want to switch them at runtime. Payment processors, discount strategies, different compression algorithms, search filters.

Real scenario: a payment processor that accepts multiple methods.

Java:

// Common interface
interface PaymentStrategy {
    void pay(double amount);
}

// Concrete strategies
class CardPayment implements PaymentStrategy {
    private final String cardNumber;

    public CardPayment(String cardNumber) {
        this.cardNumber = cardNumber;
    }

    @Override
    public void pay(double amount) {
        System.out.printf("💳 Paying $%.2f with card %s%n",
            amount, maskCard(cardNumber));
    }

    private String maskCard(String number) {
        return "****-****-****-" + number.substring(number.length() - 4);
    }
}

class CryptoPayment implements PaymentStrategy {
    private final String wallet;

    public CryptoPayment(String wallet) {
        this.wallet = wallet;
    }

    @Override
    public void pay(double amount) {
        System.out.printf("₿ Paying $%.2f with wallet %s%n",
            amount, wallet.substring(0, 8) + "...");
    }
}

class BankTransferPayment implements PaymentStrategy {
    @Override
    public void pay(double amount) {
        System.out.printf("🏦 Transferring $%.2f via bank transfer%n", amount);
    }
}

// Context — uses the strategy but doesn't know the details
class PaymentProcessor {
    private PaymentStrategy strategy;

    public void setStrategy(PaymentStrategy strategy) {
        this.strategy = strategy;
    }

    public void process(double amount) {
        if (strategy == null) {
            throw new IllegalStateException("Select a payment method");
        }
        strategy.pay(amount);
    }
}

// Usage
var processor = new PaymentProcessor();

processor.setStrategy(new CardPayment("4532123456789012"));
processor.process(149.99);
// 💳 Paying $149.99 with card ****-****-****-9012

processor.setStrategy(new CryptoPayment("0x71C7656EC7ab88b098defB751B7401B5f6d8976F"));
processor.process(149.99);
// ₿ Paying $149.99 with wallet 0x71C765...

TypeScript:

// Interface
interface PaymentStrategy {
    pay(amount: number): void;
    methodName: string;
}

// Concrete strategies
class CardPayment implements PaymentStrategy {
    methodName = "Card";

    constructor(private cardNumber: string) {}

    pay(amount: number): void {
        console.log(
            `💳 Paying $${amount.toFixed(2)} with card ****-${this.cardNumber.slice(-4)}`
        );
    }
}

class MobilePayment implements PaymentStrategy {
    methodName = "Mobile Payment";

    constructor(private phone: string, private bank: string) {}

    pay(amount: number): void {
        console.log(
            `📱 Paying $${amount.toFixed(2)} via Mobile Payment (${this.bank}, ${this.phone})`
        );
    }
}

class CryptoPayment implements PaymentStrategy {
    methodName = "Crypto";

    constructor(private wallet: string) {}

    pay(amount: number): void {
        console.log(
            `₿ Paying $${amount.toFixed(2)} with wallet ${this.wallet.slice(0, 8)}...`
        );
    }
}

// Context
class PaymentProcessor {
    private strategy: PaymentStrategy | null = null;

    setStrategy(strategy: PaymentStrategy): void {
        this.strategy = strategy;
    }

    process(amount: number): void {
        if (!this.strategy) {
            throw new Error("Select a payment method");
        }
        console.log(`\n🧾 Processing invoice: $${amount.toFixed(2)}`);
        this.strategy.pay(amount);
    }
}

// Usage
const processor = new PaymentProcessor();

processor.setStrategy(new CardPayment("4532123456789012"));
processor.process(149.99);

processor.setStrategy(
    new MobilePayment("+584140108660", "Banco de Venezuela")
);
processor.process(89.50);

processor.setStrategy(
    new CryptoPayment("0x71C7656EC7ab88b098defB751B7401B5f6d8976F")
);
processor.process(200.00);

The beauty of Strategy: adding a new payment method (PayPal, Zelle, Cash) means creating ONE new class. You don't touch PaymentProcessor. You don't modify working code. That's the Open/Closed Principle in action — open for extension, closed for modification.

3. Observer — React to Events Without Coupling

When to use it: When a state change in one object must automatically notify many others. Notifications, event systems, UI synchronization, WebSocket handlers, pub/sub architectures.

Real scenario: a server monitoring system.

Java:

import java.util.*;

// Subscriber interface
interface ServerObserver {
    void update(String serverId, String event);
}

// Publisher
class ServerMonitor {
    private final Map<String, List<ServerObserver>> subscriptions = new HashMap<>();

    public void subscribe(String serverId, ServerObserver observer) {
        subscriptions
            .computeIfAbsent(serverId, k -> new ArrayList<>())
            .add(observer);
    }

    public void unsubscribe(String serverId, ServerObserver observer) {
        List<ServerObserver> obs = subscriptions.get(serverId);
        if (obs != null) obs.remove(observer);
    }

    public void alert(String serverId, String event) {
        System.out.printf("🔔 [%s] %s%n", serverId, event);
        List<ServerObserver> obs = subscriptions.get(serverId);
        if (obs != null) {
            for (ServerObserver observer : obs) {
                observer.update(serverId, event);
            }
        }
    }
}

// Concrete subscribers
class SlackNotifier implements ServerObserver {
    @Override
    public void update(String serverId, String event) {
        System.out.printf("  📨 Slack → #oncall: Server %s — %s%n", serverId, event);
    }
}

class DatabaseLogger implements ServerObserver {
    @Override
    public void update(String serverId, String event) {
        System.out.printf("  🗄️  DB → INSERT INTO alerts (server, event, timestamp) "
            + "VALUES ('%s', '%s', NOW())%n", serverId, event);
    }
}

class AutoScaler implements ServerObserver {
    @Override
    public void update(String serverId, String event) {
        if (event.contains("CPU > 90%")) {
            System.out.printf("  ⚡ AutoScaler → Scaling server %s%n", serverId);
        }
    }
}

// Usage
var monitor = new ServerMonitor();

monitor.subscribe("prod-web-01", new SlackNotifier());
monitor.subscribe("prod-web-01", new DatabaseLogger());
monitor.subscribe("prod-web-01", new AutoScaler());

monitor.alert("prod-web-01", "CPU > 90% for 2 minutes");
// 🔔 [prod-web-01] CPU > 90% for 2 minutes
//   📨 Slack → #oncall: Server prod-web-01 — CPU > 90% for 2 minutes
//   🗄️  DB → INSERT INTO alerts (...)
//   ⚡ AutoScaler → Scaling server prod-web-01

TypeScript:

// Interfaces
interface ServerObserver {
    update(serverId: string, event: string): void;
}

// Publisher
class ServerMonitor {
    private subscriptions = new Map<string, ServerObserver[]>();

    subscribe(serverId: string, observer: ServerObserver): void {
        const existing = this.subscriptions.get(serverId) ?? [];
        existing.push(observer);
        this.subscriptions.set(serverId, existing);
    }

    unsubscribe(serverId: string, observer: ServerObserver): void {
        const observers = this.subscriptions.get(serverId);
        if (observers) {
            this.subscriptions.set(
                serverId,
                observers.filter((obs) => obs !== observer)
            );
        }
    }

    alert(serverId: string, event: string): void {
        console.log(`🔔 [${serverId}] ${event}`);
        const observers = this.subscriptions.get(serverId);
        if (observers) {
            observers.forEach((obs) => obs.update(serverId, event));
        }
    }
}

// Subscribers
class SlackNotifier implements ServerObserver {
    update(serverId: string, event: string): void {
        console.log(`  📨 Slack → #oncall: Server ${serverId} — ${event}`);
    }
}

class PagerDutyNotifier implements ServerObserver {
    update(serverId: string, event: string): void {
        if (event.includes("CRITICAL")) {
            console.log(
                `  🚨 PagerDuty → ESCALATING: ${serverId} requires immediate attention`
            );
        }
    }
}

class MetricsLogger implements ServerObserver {
    update(serverId: string, event: string): void {
        const timestamp = new Date().toISOString();
        console.log(
            `  📊 Metrics → { server: "${serverId}", event: "${event}", ts: "${timestamp}" }`
        );
    }
}

// Usage in a real monitoring system
const monitor = new ServerMonitor();

monitor.subscribe("prod-api-03", new SlackNotifier());
monitor.subscribe("prod-api-03", new PagerDutyNotifier());
monitor.subscribe("prod-api-03", new MetricsLogger());

monitor.alert("prod-api-03", "CRITICAL: Disk at 98%");

Observer is ubiquitous in modern development: Redux is Observer. WebSocket handlers are Observer. DOM event listeners are Observer. Understanding the pattern makes you understand half a dozen libraries and frameworks automatically.

How to Start Without Overwhelming Yourself

Don't try to memorize all 23 patterns. It's useless. Better:

Learn the 5 essentials first: Singleton, Factory Method, Strategy, Observer, and Decorator. They cover 80% of real-world cases.
Identify them in your stack: Spring Boot is full of Template Method and Proxy. Angular uses Observer through RxJS. React depends on Observer with its Virtual DOM. Node.js uses Strategy in Express middlewares. Find them in what you ALREADY use.
Practice reverse refactoring: Take old smelly code — a 500-line class, a 20-branch if/else — and ask: what pattern could tame this? Then refactor applying it.
Read Refactoring.Guru: It's the best free resource out there. Visual explanations, pseudocode, examples in 10 languages, and zero unnecessary academic fluff. If you only take one recommendation from this article, make it this one: refactoring.guru
Don't turn everything into a pattern: This is the newly-converted mistake. You start seeing Singletons everywhere. The pattern should simplify, not complicate. If applying a pattern makes your code harder to read, don't apply it. Simple > Elegant.

Conclusion

Design patterns don't make you a better developer because you know their names. They make you a better developer because they teach you to think in structures, in responsibilities, in long-term consequences.

They're the coding equivalent of knowing chess openings instead of just moving pieces to see what happens. You can play without knowing them. But knowing them, the game changes.

And the best part: once you start recognizing patterns, you stop seeing code. You start seeing shapes, intentions, structure. Other people's code — and your own — reads with different eyes.

Do you use design patterns daily without realizing it? What was the first one you learned? Tell me. Mine was Singleton — and I used it wrong for two years until I understood when NOT to use it.