📐 Design Patterns

The Recipe Analogy

When you want to make bread, you don't experiment from scratch every time. You follow a recipe that thousands of bakers have refined over centuries.

Design patterns are recipes for code.

They're proven solutions to problems that developers encounter again and again:

• "How do I make sure I have a single shared instance?"
• "How do I create objects without specifying exact types?"
• "How do I notify many objects when something changes?"

Instead of reinventing solutions, you can apply patterns that experienced developers have tested and refined over decades.

Why Design Patterns Matter

Imagine every developer invented their own way to:

• Connect to databases
• Handle user events
• Create complex objects
• Manage application state

Code would be chaos! Every codebase would work differently.

Design patterns give us:

• Shared vocabulary - "Let's use the Observer pattern" is clearer than explaining from scratch
• Proven solutions - These have been tested in real-world systems
• Better communication - Developers worldwide understand the same patterns
• Faster development - Don't solve solved problems

The Three Categories

Design patterns fall into three groups based on what problem they solve:

Think of it this way:

• Creational = Birth (how things come into existence)
• Structural = Body (how things are organized)
• Behavioral = Actions (how things interact)

Singleton: "One Shared Instance"

The Problem:

Some things are often easier to manage as a single shared instance (for example, a configuration service or a database connection pool).

The Real-World Analogy:

A country has one president. A building has one main entrance. Your app has one database connection pool.

How It Works:

The first time you ask for the instance, it's created. Every subsequent request returns that same instance.

class Database {
  static instance = null;

  constructor() {
    if (Database.instance) {
      return Database.instance; // Return existing
    }
    this.connection = "Connected";
    Database.instance = this; // Save for later
  }
}

const db1 = new Database();
const db2 = new Database();
console.log(db1 === db2); // true - same instance!

When to Use: Database connections, configuration managers, logging services.

Watch Out: Singletons make testing harder (hard to isolate) and can hide dependencies.

Factory: "Object Creation Made Easy"

The Problem:

Creating objects can be complex. What if you need different types based on user input? What if creation logic is complicated?

The Real-World Analogy:

A car factory doesn't make you specify every part. You say "I want a sedan" and the factory handles the details - engine, chassis, wheels, everything.

How It Works:

Instead of calling new directly, you ask a factory to create objects for you.

class VehicleFactory {
  static create(type) {
    switch (type) {
      case "car":
        return new Car();
      case "truck":
        return new Truck();
      case "bike":
        return new Motorcycle();
      default:
        throw new Error("Unknown type");
    }
  }
}

// Simple! Just tell the factory what you want
const vehicle = VehicleFactory.create("car");

When to Use: Object creation varies by type, requires complex setup, or you want to hide creation details.

Observer: "When Something Happens, Notify Subscribers"

The Problem:

When one thing changes, other things need to know. But you don't want tight coupling - the thing that changes shouldn't need to know about everything watching it.

The Real-World Analogy:

Newsletter subscriptions! The magazine doesn't need to know each subscriber personally. You subscribe, and when a new issue comes out, subscribers get notified.

How It Works:

Objects "subscribe" to events. When something happens, all subscribers are notified.

Newsletter (Subject) ←── Alice subscribes
                     ←── Bob subscribes
                     ←── Carol subscribes

When new issue published:
  → Notify Alice
  → Notify Bob
  → Notify Carol

When to Use: Event systems, UI updates when data changes, notifications, pub/sub messaging.

Example: When a user places an order:

• Inventory system needs to update stock
• Email system needs to send confirmation
• Analytics needs to log the sale

Instead of the order system knowing about all three, they all subscribe to "order placed" events.

Strategy: "Swap Behaviors Like LEGO Pieces"

The Problem:

You need to do the same thing in different ways. Payment processing: credit card, PayPal, crypto. Sorting: quick sort, merge sort, bubble sort.

The Real-World Analogy:

GPS navigation with different route strategies: time-optimized, distance-optimized, avoid tolls, scenic. Same destination, different algorithms.

How It Works:

Define a family of algorithms and make them interchangeable.

Navigation System
  └── uses Strategy: "Time-Optimized Route"
      (can swap to "Distance-Optimized" or "Scenic")

When to Use: Multiple algorithms for the same task, need to switch behavior at runtime, want to avoid complex if-else chains.

Adapter: "Making Incompatible Things Work Together"

The Problem:

You have old code with one interface. You have new code expecting a different interface. You can't change either.

The Real-World Analogy:

Travel adapters! Your US laptop plug doesn't fit European outlets. The adapter sits in between, translating one format to another.

How It Works:

Create a wrapper that converts one interface to another.

Old System: calculator.operations(5, 3, "add")
New System expects: calculator.add(5, 3)

Adapter translates:
  .add(a, b) → .operations(a, b, "add")

When to Use: Integrating legacy code, using third-party libraries with different interfaces, gradual migration between systems.

Facade: "One Simple Door to a Complex Building"

The Problem:

A system has many complex parts. Users shouldn't need to understand all of them to use it.

The Real-World Analogy:

A hotel front desk. You don't talk to the cleaning department, the kitchen, the maintenance crew. You talk to ONE person (the front desk) who handles everything for you.

How It Works:

Create a simple interface that internally coordinates multiple complex systems.

Complex:
  CPU.freeze() → Memory.load() → HardDrive.read() → CPU.execute()

Facade:
  Computer.start()  // Handles all the complexity

When to Use: Simplifying complex subsystems, providing a clean API, hiding implementation details from clients.

When to Use (and NOT Use) Patterns

Use Patterns When:

• You recognize a problem pattern specifically solves
• The pattern makes your code clearer and more maintainable
• You're building for the long term
• You need to communicate with other developers

DON'T Use Patterns When:

• A simple solution works fine
• You're adding complexity for complexity's sake
• You don't fully understand the pattern
• The pattern doesn't fit the problem

"Make it work, make it right, make it fast." Patterns help with "make it right" - don't use them before "make it work."

Common Mistakes

Mistake 1: Pattern Obsession

Using patterns everywhere, even when unnecessary:

// Over-engineering
class StringReaderFactoryBuilderManager...

// Just use
const text = "hello";

Mistake 2: Using the Wrong Pattern

Applying Singleton when you actually need multiple instances. Using Observer when events aren't the problem.

Solution: Understand the problem FIRST. Then find the pattern that fits.

Mistake 3: Ignoring Trade-offs

Every pattern has costs:

• Singleton makes testing harder
• Observer can create memory leaks if you forget to unsubscribe
• Factory adds indirection

FAQ

Q: How many patterns should I learn?

Start with the essentials: Singleton, Factory, Observer, Strategy. Learn others as you encounter the problems they solve.

Q: Do small projects need patterns?

Often not. Patterns shine in larger systems. For a simple script, they're overkill.

Q: How do I know which pattern to use?

Understand your problem first. Patterns are solutions - you need to know your problem before picking a solution.

Q: Are patterns the same in all languages?

The concepts are universal. Implementation varies. Some languages have patterns built-in (decorators in Python, Promises in JavaScript).

Q: Where did design patterns come from?

A well-known book by four authors (often called the “Gang of Four”) popularized a catalog of commonly used patterns that had been observed in real-world software.

Q: What are anti-patterns?

Common BAD solutions that seem good but cause problems: God Object (one class does everything), Spaghetti Code, Copy-Paste Programming.

Summary

Design patterns are reusable solutions to common programming problems. They give developers a shared vocabulary and proven approaches.

Key Takeaways:

• Patterns are recipes, not rules
• Three categories: Creational, Structural, Behavioral
• Start with: Singleton, Factory, Observer, Strategy
• Use when they clarify code, not complicate it
• Understand the problem before applying patterns
• Every pattern has trade-offs

Patterns are tools in your toolbox. Know them well, but don't force them where they don't fit!