Refactoring toward patterns

A pattern is a destination, not a starting point. The Gang-of-Four catalogue describes recurring solutions; it does not tell you when the problem is present. Kerievsky’s reframing — “refactor to patterns” — treats each pattern as the target of a series of small, behaviour-preserving refactorings, applied only once the code exhibits the smell that pattern dissolves. You don’t decide “this needs a Strategy” in a design meeting; you notice a conditional that keeps growing along one axis, and that observation is what makes Strategy the right move. The pattern earns its place by removing a concrete pain, not by appearing in a textbook.

The practical consequence: you never write interface PaymentStrategy on day one. You write the simplest thing, and you let the second and third payment method show you the duplication before you extract the abstraction.

Duplicated construction logic pulls you toward a Factory. When the same multi-step object-creation appears in several call sites — and especially when the type being created depends on a runtime value — the smell is duplicated, branching construction. The refactoring that removes it lands you on a factory.

// SMELL: the same "which class?" decision is duplicated at every call site
const a = type === "pdf" ? new PdfReport(data) : new CsvReport(data);
// ...elsewhere, again:
const b = kind === "pdf" ? new PdfReport(other) : new CsvReport(other);

The decision “which Report subclass” is copy-pasted. Centralise it:

function createReport(type: string, data: Data): Report {
  if (type === "pdf") return new PdfReport(data);
  return new CsvReport(data);
}
const a = createReport(type, data);
const b = createReport(kind, other);

Now a new format is one edit inside createReport; callers depend on the concept “make a report”, not on the concrete classes. You didn’t plan a Factory — you removed duplication and a Factory is what the duplication-removal produced.

A conditional that grows along one axis pulls you toward Strategy. A switch or if-chain that keeps gaining branches for the same reason — a new shipping method, a new pricing rule, a new export format — is the “switch statements” smell. Each branch is an interchangeable algorithm wedged into one function. Strategy is where removing that smell takes you: pull each branch into its own object behind a shared interface, and the conditional collapses into a lookup.

// SMELL: one function that grows a branch every time a method is added
function shippingCost(method: string, weight: number): number {
  if (method === "standard") return weight * 1.5;
  if (method === "express")  return weight * 1.5 + 10;
  if (method === "overnight") return weight * 3 + 25;
  throw new Error("unknown method");
}

Refactor toward Strategy — but only once the third or fourth branch has proven the axis is real:

type ShippingStrategy = (weight: number) => number;
const strategies: Record<string, ShippingStrategy> = {
  standard:  (w) => w * 1.5,
  express:   (w) => w * 1.5 + 10,
  overnight: (w) => w * 3 + 25,
};
function shippingCost(method: string, weight: number): number {
  const strategy = strategies[method];
  if (!strategy) throw new Error("unknown method");
  return strategy(weight);
}

Adding a method is now an entry in the map, not a branch in a growing function — and unrelated methods stop sharing a code path you have to re-test.

A conditional that branches on a lifecycle phase pulls you toward State. Strategy’s cousin: when the conditional isn’t choosing an algorithm but checking “what mode am I in right now?” — and transitions between modes are scattered as this.status = "..." assignments — the pull is toward the State pattern. The tell is a status field that several methods all branch on, with the same if (status === ...) ladder repeated.

// SMELL: every method re-derives behaviour from a status string
class Order {
  status = "draft";
  submit() { if (this.status !== "draft") throw Error("can't submit"); this.status = "submitted"; }
  pay()    { if (this.status !== "submitted") throw Error("can't pay"); this.status = "paid"; }
  cancel() { if (this.status === "paid") throw Error("can't cancel"); this.status = "cancelled"; }
}

State extracts each phase into its own object that owns its legal transitions, so an illegal transition is impossible by construction rather than guarded by a chain of string checks. But notice the cost: State is heavier than Strategy. For three states you might keep the explicit checks; the pattern earns itself only when the number of states and transitions makes the scattered ladder genuinely hard to reason about. The smell — duplicated if (status === ...) across many methods — is the gate.