Factory Method

Three different structures get called "a factory", and conflating them is why the pattern has a reputation for being pointless ceremony. This topic separates them, then argues that the smallest one is usually the right one.

The problem all three attack is the same: a caller that has to know which concrete class to build is coupled to every class it might build, and construction logic that lives at the call site gets duplicated at every call site.

// Scattered through the codebase, in four different files
const client = config.provider === 'stripe'
  ? new StripeClient(config.key, { timeoutMs: 5000, retries: 3 })
  : new RazorpayClient(config.key, { timeout: 5000 });

Every file that does this knows both vendors exist, knows their constructor shapes, and has its own copy of the retry policy. Adding a third vendor is a search-and-replace.

The three things called "factory"

A simple factory is one function with the decision inside. It is not in the classic catalogue and it is what you want most of the time.

Factory Method is the catalogue entry: a base class defines an operation that creates something, and subclasses decide what. The base class never names a concrete product.

Abstract Factory creates families of related objects that must be consistent with one another. It gets its own topic next.

The simple factory

One place decides, and every caller stops knowing:

export function createPaymentClient(config) {
  switch (config.provider) {
    case 'stripe':
      return new StripeClient(config.key, { timeoutMs: 5000, retries: 3 });
    case 'razorpay':
      return new RazorpayClient(config.key, { timeout: 5000 });
    default:
      throw new Error(`Unknown payment provider: ${config.provider}`);
  }
}

Three things this bought, and it is worth being precise because people claim it buys more:

• The retry policy exists once. That is the duplication actually removed.
• Callers name a capability, not a vendor. They hold whatever createPaymentClient returns.
• Adding a provider edits one file. The default branch means an unknown value fails loudly at startup rather than producing undefined and a null-reference error three layers away.

What it did not buy: the switch statement still exists. A factory does not delete the conditional, it relocates it to one place and runs it once. That is the entire trick, and it is enough.

Factory Method proper

Factory Method appears when a base class owns an algorithm but must not know what it is operating on.

classDiagram
    class ReportJob {
        +run(rows) void
        #createFormatter()* Formatter
    }
    class PdfReportJob {
        #createFormatter() Formatter
    }
    class CsvReportJob {
        #createFormatter() Formatter
    }
    class Formatter {
        <<interface>>
        +format(rows) bytes
    }
    ReportJob <|-- PdfReportJob
    ReportJob <|-- CsvReportJob
    ReportJob ..> Formatter

class ReportJob {
  run(rows) {
    const formatter = this.createFormatter();   // the factory method
    const bytes = formatter.format(rows);
    this.upload(bytes);
    this.recordMetrics(rows.length);
  }
  createFormatter() { throw new Error('subclass must implement'); }
}

class CsvReportJob extends ReportJob {
  createFormatter() { return new CsvFormatter(); }
}

ReportJob owns the sequence — format, upload, record — and never names a formatter. This is the Hollywood principle again: the base class calls down at the one point that varies.

Notice what makes this Factory Method rather than a simple factory: the choice is bound by which subclass you instantiated, not by an argument. That is a real difference in where the decision lives, and it is why Factory Method is often a Template Method with one overridable step that happens to return an object.

When a factory earns nothing

Construction is a plain new. createUser(name, email) returning new User(name, email) is a rename with extra indirection.

There is one implementation. The switch has one arm. You have added a file to express a constant.

The caller already knows which one it wants. If every call site passes 'stripe' explicitly, the decision was never centralised — it was just moved into a string.

The honest test: can you name the decision the factory makes? "It picks the provider from configuration" is a decision. "It calls the constructor" is not.

Where the object graph actually gets built

A factory answers "which class", not "who wires the whole application". Those get confused constantly.

In practice a system has a composition root — one place, usually near start-up, where configuration is read and the object graph is assembled. Factories live there. Everything below receives its collaborators rather than reaching for a factory, because a class calling a factory has simply swapped one hidden dependency for another.

Check your understanding

Common mistakes

Factories that only call new. If construction involves no decision, the factory is a rename.

A factory per class. UserFactory, OrderFactory, InvoiceFactory, each with one method that constructs one thing. This is a naming convention, not a design.

Calling factories deep inside business logic. It hides the dependency and forces tests to fake the factory rather than the collaborator.

No default branch. An unrecognised provider string returning undefined fails far from its cause. Throw at the decision point.

Subclassing purely to change what one method returns. Pass the object in. Inheritance is a heavy way to express a value.

Naming the class after the pattern. PaymentClientFactoryImpl describes the mechanism; PaymentClients or createPaymentClient describes the job.

Practice

class ReportJob {
  constructor(formatter) { this.formatter = formatter; }
  run(rows) { this.upload(this.formatter.format(rows)); }
}

Key takeaways

• Three structures share the name: a simple factory (one function, one decision), Factory Method (a subclass chooses), and Abstract Factory (a consistent family).
• A factory does not delete the conditional — it stops the conditional and the construction details from being copied to every call site.
• Name the decision the factory makes. If you cannot, it is a rename.
• Factory Method binds the choice by subclass, which is right for a family of behaviours and wrong for expressing a single value — inject the value instead.
• Always have a default branch that throws. Unknown configuration should fail at start-up, not as a null reference three layers deep.
• Call factories at the composition root, not inside business logic — a factory called deep in a service is still a hidden dependency.

Further reading

• Erich Gamma, Richard Helm, Ralph Johnson and John Vlissides, Design Patterns: Elements of Reusable Object-Oriented Software (Addison-Wesley, 1994).
• Joshua Bloch, Effective Java, third edition (Addison-Wesley, 2018) — the case for static factory methods over constructors.
• Mark Seemann and Steven van Deursen, Dependency Injection Principles, Practices, and Patterns (Manning, 2019) — the composition root.
• Martin Fowler, Patterns of Enterprise Application Architecture (Addison-Wesley, 2002).
• Michael Feathers, Working Effectively with Legacy Code (Prentice Hall, 2004) — extracting a factory as a seam for testing.