Factory Method

Triggered by

Reached from

Introduce Polymorphic Creation With Factory Method

Symptom

A class's constructor (or initialization method) switches on a type code to choose which concrete subtype to instantiate. The switch grows a new branch every time a new variant ships; the class accumulates knowledge of every product that exists. The team's verification cost compounds across every variant a reviewer must check, paying comprehension cost on every read.

Goal

The base class owns the workflow and exposes one virtual hook — the factory method — that subclasses override to choose the product. The creator never names a concrete product; new variants subclass the creator instead of editing it, supporting separation of concerns between workflow and product selection.

Before the pattern

class Document {
  open(format) {
    let page;
    if (format === 'pdf') {
      page = new PdfPage();
    } else if (format === 'html') {
      page = new HtmlPage();
    } else if (format === 'markdown') {
      page = new MarkdownPage();
    } else {
      throw new Error(`unknown format: ${format}`);
    }
    this.pages = [page];
  }
}

After the pattern

class Document {
  open() {
    const page = this.createPage();
    this.pages = [page];
  }
  createPage() {
    throw new Error('createPage must be implemented by subclass');
  }
}
class PdfDocument extends Document {
  createPage() { return new PdfPage(); }
}
class HtmlDocument extends Document {
  createPage() { return new HtmlPage(); }
}
class MarkdownDocument extends Document {
  createPage() { return new MarkdownPage(); }
}

Example source: Illustrative example written for this site in the spirit of Design Patterns (Gamma, Helm, Johnson, Vlissides, Addison-Wesley, 1994), chapter 3. The book's running example is a Document framework with Pages; this JavaScript adaptation keeps the canonical Creator (Document) + Product (Page) hierarchy and shows the factory-method hook deferring product instantiation to subclasses.

Pressure

Adding a new product requires editing the creator's switch in addition to writing the new product class. Open-Closed is broken at the creator: existing code must change to accommodate each new product. Tests for the creator multiply by variant count. The blast radius of any new variant stretches into the creator's body, raising cognitive load on every reader.

Tradeoff

Subclassing the creator for every product makes a parallel hierarchy that doubles the class count and forces the codebase to live with type-tag selection at the creator-subclass level. Some teams find the indirection more confusing than the switch it replaced. The team's maintenance cost per variant moves from one switch edit to one new file.

Relief

The creator's workflow reads as 'do A, ask the hook for the product, do B with it.' Adding a new product is a new subclass — no existing code changes. Each subclass is small, independently testable, and obvious in intent: 'this is the X variant of Document.' The team's enhancement cost drops because new variants ship without touching the creator.

Trap

The factory method hook degenerates into a Template Method with multiple hooks the subclass must override in lockstep. When subclasses must override two or more methods to be coherent — createPage, validatePage, indexPage — the parallel hierarchy stops paying; reach for composition or Strategy instead. The cure adds accidental complexity when the hook set exceeds what one variant axis justifies.