Factory Method

The moving parts

A factory setup has three roles. Once you see them, you'll spot the pattern everywhere:

• A product interface — the shared contract every created object promises to honor. Here it's Notification with one method, send(message). The caller only ever talks to this.
• Concrete products — the real classes that implement the interface: EmailNotification, SmsNotification, PushNotification. Each does send() its own way, but from the outside they look identical.
• The factory — the one place that decides which concrete product to build. The caller hands it a channel and gets back a Notification, never touching new itself.

// The one place 'new' lives — everyone else stays clean.
class NotificationFactory {
  static create(channel: string): Notification {
    switch (channel) {
      case "email": return new EmailNotification();
      case "sms":   return new SmsNotification();
      case "push":  return new PushNotification();
      default: throw new Error("Unknown channel: " + channel);
    }
  }
}

// Client code — identical no matter which channel.
const n = NotificationFactory.create(user.channel);
n.send("Your order shipped 📦");

Look at the last two lines: that's the entire client. It never says new EmailNotification(). It asks the factory for a notification and calls send(). Switch user.channel from "email" to "sms" and those two lines don't change at all — only the factory's internal branch and the returned product differ. That's the decoupling the pattern buys you.

"Simple factory" vs the real Gang-of-Four Factory Method

The version above — one create(channel) method with a switch — is what most people first meet, and it's often called a simple factory. It's a great on-ramp and it captures the key benefit (creation lives in one place). But it's not quite the pattern the original Gang of Four book named "Factory Method."

The true Factory Method replaces the switch with inheritance. You have a base Creator class with a factory method — an overridable method like createNotification() — that returns the product. The base class contains the shared workflow and calls that method, but each subclass decides which concrete product to build by overriding it:

// The 'Creator' base class defines the workflow and a factory method.
abstract class Notifier {
  abstract createNotification(): Notification;  // the factory method

  notify(msg: string): void {          // shared workflow, written once
    const n = this.createNotification();
    n.send(msg);
  }
}

// Each subclass decides the concrete product — no switch anywhere.
class EmailNotifier extends Notifier {
  createNotification() { return new EmailNotification(); }
}
class SmsNotifier extends Notifier {
  createNotification() { return new SmsNotification(); }
}

Both forms solve the same problem: the code that uses a product doesn't hard-code which concrete class it gets. The simple-factory switch picks the product at runtime from a value; the classic Factory Method picks it by which subclass you instantiated. Start with the simple factory in your head — it's the beginner-friendly on-ramp — and reach for the subclass version when different subclasses genuinely need different creation logic.

Why the client never changes when you add a channel

Say a new requirement lands: also notify by WhatsApp. With direct new calls scattered around, you'd edit every call site. With a factory, you do exactly two small things: (1) write a new WhatsAppNotification class that implements send(), and (2) add one branch to the factory. Every existing caller — every NotificationFactory.create(...); n.send(...) in the whole codebase — keeps working untouched. You extended the system without modifying the code that uses it. The prototype lets you feel this: add WhatsApp and watch the client-code panel report a diff of 0 lines.

Reach for a factory when creation shouldn't be the caller's problem

A factory earns its keep whenever the decision of which class to build is likely to change or grow, and you don't want that decision smeared across your codebase:

• You have a family of interchangeable types behind one interface — notification channels, payment providers, file exporters (PDF/CSV/XLSX), database drivers. New members get added over time and every caller should keep working.
• The concrete type is chosen at runtime — from config, a user setting, a request field, or an environment. The caller has a value ("sms") and wants an object; the factory bridges the two.
• Construction has real logic — picking a class, wiring dependencies, reading a flag. Hiding that behind create(...) keeps callers simple and puts the messy part in one testable place.
• You want to honor Open/Closed — adding a type should mean adding code (a new product + a branch), not editing every place that creates one.