Factory Method & Abstract Factory: Decoupling Object Creation

Intent (one line each)

• Factory Method — Define an interface for creating one object, but let subclasses decide which concrete class to instantiate.
• Abstract Factory — Provide an interface for creating families of related objects without naming their concrete classes.

Both are creational patterns. Both exist to delete one specific line from your client code: the new ConcreteThing(). Everything else follows from that.

The Problem They Solve

Direct instantiation hard-wires a caller to a concrete class:

class OrderService {
    notify(order) {
        const ch = new EmailChannel();   // <-- the offending line
        ch.send(order.userEmail, "Order shipped");
    }
}

Three things just went wrong:

1. OrderService now depends on EmailChannel — a concrete, leaf-level class. It can never send an SMS without being edited.
2. The decision of which channel to use is buried inside business logic, scattered across every call site. Add a PushChannel and you grep for new EmailChannel across the codebase.
3. It is untestable in isolation — you cannot inject a fake channel; the new is welded in.

The root cause is that selecting a concrete type and using it are two different responsibilities that got fused. Factory patterns split them apart: a creation seam (“which class?”) on one side, polymorphic use (“call send”) on the other.

Factory Method vs Abstract Factory — the one-sentence distinction

Factory Method creates one product through a single overridable method. Abstract Factory creates a set of products that must be used together (a family) through an object that bundles several creation methods.

If you only ever vary one product, Factory Method. If varying one choice (say, “macOS theme”) forces a coordinated set of choices (MacButton + MacCheckbox + MacMenu that must match), Abstract Factory.

Structure (ASCII UML)

Factory Method

            +----------------------+              +------------------+
            |   Creator (abstract) |              |    Product       |  <<interface>>
            +----------------------+              +------------------+
            | + someOperation()    |    creates   | + use()          |
            | # createProduct():   |- - - - - - ->+------------------+
            |       Product  {abs} |                      ^
            +----------------------+                      |
                       ^                          +-------+--------+
                       |                          |                |
          +------------+-----------+      +----------------+ +----------------+
          | ConcreteCreatorA       |      | ConcreteProductA| | ConcreteProductB|
          +------------------------+      +----------------+ +----------------+
          | # createProduct():     |--------------^
          |       ConcreteProductA |
          +------------------------+

someOperation() calls the abstract createProduct(); the subclass binds it.

The shape above is the Non-Virtual Interface (NVI) idiom: the public, non-overridable someOperation() invokes the protected, overridable createProduct(). The base class owns the algorithm; subclasses own only the creation step. We use this exact arrangement in the C++ example below — and it is worth naming in an interview, because it shows you know why the factory method is protected rather than public.

Abstract Factory

        +--------------------------+         +------------------+
        | AbstractFactory  {abs}   |         | AbstractProductA |  <<interface>>
        +--------------------------+ creates +------------------+
        | + createButton(): A      |- - - - >|                  |
        | + createCheckbox(): B    |- - +    +------------------+
        +--------------------------+    |     +------------------+
                  ^                     +- - >| AbstractProductB |  <<interface>>
        +---------+----------+               +------------------+
        |                    |
+----------------+  +----------------+
| MacFactory     |  | WinFactory     |
+----------------+  +----------------+
| createButton() |  | createButton() |  --> returns MacButton / WinButton
| createCheckbox()| | createCheckbox()|  --> returns MacCheckbox / WinCheckbox
+----------------+  +----------------+

One factory instance produces one variant's products. The "consistent family"
holds only as long as the client draws BOTH products from the SAME instance.

Participants

A useful mental note: Abstract Factory is conventionally described as being implemented with several Factory Methods (the GoF phrasing). Be precise about what that means. A true GoF Factory Method is an overridable method that a subclass of the creator binds. The per-variant createFormatter() / createTransport() you will see in our EmailFactory / SmsFactory below are concrete, non-overridden methods — each variant just hard-returns its own product. That is closer to the Simple Factory idiom living inside each concrete factory. The composition claim is defensible and traditional, but in an interview you should add the nuance: “Abstract Factory’s creation methods are abstract on the factory interface; whether each concrete factory implements them via a true subclass-overridable Factory Method or just a direct new is an implementation detail — most real code does the latter.”

Real-World Example: a Notification Subsystem

Forget the textbook shapes. Here is a recurring backend problem: you must deliver notifications over email, SMS, and push, the channel is chosen at runtime (user preference, message urgency, A/B config), and adding a new channel must not touch existing call sites. That is Factory Method territory — one product (NotificationChannel), type varies.

// ----- Product -----
interface NotificationChannel {
send(to: string, subject: string, body: string): void;
}

class EmailChannel implements NotificationChannel {
send(to: string, subject: string, body: string): void {
  console.log(`EMAIL -> ${to}: ${subject}\n${body}`);
}
}
class SmsChannel implements NotificationChannel {
send(to: string, _subject: string, body: string): void {
  // NOTE: the 160-char GSM limit is enforced HERE, in the channel.
  console.log(`SMS -> ${to}: ${body.slice(0, 160)}`);
}
}

// ----- Creator -----
abstract class Notifier {
// The Factory Method (overridable by subclasses):
protected abstract createChannel(): NotificationChannel;

// NVI: the public algorithm USES the product, unaware of its type:
notify(to: string, subject: string, body: string): void {
  const channel = this.createChannel();
  channel.send(to, subject, body);
}
}

class EmailNotifier extends Notifier {
protected createChannel(): NotificationChannel { return new EmailChannel(); }
}
class SmsNotifier extends Notifier {
protected createChannel(): NotificationChannel { return new SmsChannel(); }
}

// ----- Client -----
const notifier: Notifier = new SmsNotifier();   // chosen by config/DI
notifier.notify("+15550100", "Shipped", "Your order is on its way!");

When one choice forces a whole family: Abstract Factory

Now raise the stakes. Each channel needs two collaborating objects that must match: a MessageFormatter (how to lay out the payload) and a Transport (the wire client). An SMS payload must be formatted and transported the SMS way — you must never pair an EmailFormatter with an SmsTransport. The choice of channel selects a consistent family. That is Abstract Factory.

Notice a deliberate responsibility shift from the previous example: in Factory Method the 160-char SMS truncation lived in SmsChannel.send (a transport concern). Here it lives in SmsFormatter.format, and SmsTransport.deliver does no truncation at all. That is intentional — once formatting is its own product, layout/length rules belong to the formatter, not the transport. When you split a god-object into a family, you also get to re-home its responsibilities; call that out rather than letting it drift silently.

interface MessageFormatter { format(subject: string, body: string): string; }
interface Transport { deliver(to: string, payload: string): void; }

// ----- Abstract Factory -----
interface ChannelFactory {
createFormatter(): MessageFormatter;
createTransport(): Transport;
}

// ----- Email family -----
class EmailFormatter implements MessageFormatter {
format(s: string, b: string) { return `Subject: ${s}\n\n${b}`; }
}
class EmailTransport implements Transport {
deliver(to: string, p: string) { console.log(`[smtp] ${to}\n${p}`); }
}
class EmailFactory implements ChannelFactory {
createFormatter() { return new EmailFormatter(); }
createTransport() { return new EmailTransport(); }
}

// ----- SMS family -----
class SmsFormatter implements MessageFormatter {
// 160-char limit now lives in the FORMATTER (layout concern), not transport.
format(_s: string, b: string) { return b.slice(0, 160); }
}
class SmsTransport implements Transport {
deliver(to: string, p: string) { console.log(`[sms-gw] ${to}: ${p}`); }
}
class SmsFactory implements ChannelFactory {
createFormatter() { return new SmsFormatter(); }
createTransport() { return new SmsTransport(); }
}

// ----- Client: depends only on the abstract factory -----
// Consistency is guaranteed ONLY because both products come from the SAME 'f'.
function dispatch(f: ChannelFactory, to: string, subj: string, body: string) {
const payload = f.createFormatter().format(subj, body);  // family member A
f.createTransport().deliver(to, payload);                // family member B (matched via f)
}

dispatch(new SmsFactory(), "+15550100", "Shipped", "Your order is on its way!");

When To Use — and When NOT To

Use Factory Method when:

• One product type varies and you want subclasses (not a switch) to choose it, often as the variable step of a Template Method.
• You are writing a framework: the base class calls createX(), and downstream users subclass to supply their type.

Use Abstract Factory when:

• You have two or more products that must be used together and mismatching them is a bug (formatter+transport, button+checkbox+menu, parser+serializer for one wire format).
• You switch whole families at once (platform, cloud provider, on-prem vs SaaS driver set).

Do NOT use them when:

• The concrete type never varies at runtime. If notifications are always email, an EmailNotifier hierarchy is pure ceremony — just call new EmailChannel(). The pattern earns its keep only when the variance is real.
• There is exactly one family member. An “Abstract Factory” with a single createX() is just a Factory Method wearing a costume; collapse it.
• A registry/Simple Factory is enough. If you never need a subclass to override creation, a Map<enum, supplier> is simpler than a Creator hierarchy and stays Open/Closed.
• You are guessing at future variance. Adding the seam “in case we need SMS later” is speculative generality (YAGNI). Add the factory when the second implementation actually arrives.

Relationship to SOLID

• DIP (Dependency Inversion): This is the whole point. The client depends on the NotificationChannel / ChannelFactory abstraction, never on EmailChannel. High-level policy stops depending on low-level detail.
• OCP (Open/Closed): Adding a new variant is a new class, not an edit to callers — along the variant axis (see the pitfall above for the limit).
• SRP (Single Responsibility): “Decide which class” is lifted out of “use the object.” The creator owns selection; the client owns behavior.
• LSP (Liskov): Every concrete product must be substitutable behind the product interface, or the polymorphic notify/dispatch breaks. The pattern relies on LSP holding.

Siblings It Gets Confused With

• Simple / Static Factory — a method that switches on a parameter. Not a GoF pattern. No subclassing. Great default; reach for the real patterns only when you need the inheritance seam or the family.
• Builder — also creational, but solves a different problem: constructing one complex object step by step (many optional parts), not selecting among types or families. Factory answers “which class?”; Builder answers “how to assemble this one instance.”
• Prototype — creates new objects by cloning an existing instance rather than calling a constructor. Use it when instantiation is expensive or the concrete type is only known as a live object.
• Template Method — Factory Method is frequently the customizable step inside a Template Method (notify() is the template; createChannel() is the hook). They co-occur constantly.