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.
Type-code dispatch in a constructor or initializer means the agent holds the full enumeration of variants in context while reading or editing the class. New variants land as edits to the switch; missed variants ship as runtime errors the agent had no structural reason to catch. The agent's verification-surface cost multiplies with variant count.
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.
Structural completeness via the type system: every subclass of the creator implements the factory method, so missing-variant bugs surface as construction-time errors the agent sees during static reading. The creator's workflow becomes a stable surface the agent never re-reads as products multiply, and type-checker visibility of incomplete subclasses replaces enumeration in working context.
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(); }}
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.
The agent's verification budget on creator edits scales linearly with the number of variants in the switch. Every variant must be checked for consistent treatment; partial updates produce type-compatible silent bugs the test suite may not exercise. The agent's context-window load climbs faster than feature value, and the retrieval cost of each variant body is per-edit overhead.
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.
A parallel hierarchy doubles the file count the agent navigates. Variant identification becomes an additional step in every reasoning trace, and refactoring across the hierarchy requires editing N files in lockstep — the cross-cutting pattern with the highest per-edit token cost. The agent's completeness-check cost on hierarchy edits scales linearly with subclass count.
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.
Adding a new variant is one new subclass that overrides the factory method; the creator's body stays constant in size, and the agent generates the new subclass by reading one sibling rather than editing dispatch logic. The agent's context window holds the sibling and the new subclass; the reasoning step count drops because no creator-side edit is required.
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.
Subclasses that override more than the factory method (extra hooks, extra state, extra invariants) reintroduce the cross-cutting verification problem — the agent verifies N subclasses each implement M hooks consistently. The parallel hierarchy becomes the same N×M cell-check, now spread across more files, and the reasoning-step cost per consistency check multiplies with M.