Compose Method

Triggered by

Symptom

A method that switches between abstraction levels mid-body — control statements, low-level mutations, validation, and high-level orchestration interleaved. Readers have to mentally separate the algorithm from the bookkeeping every time they open the file. The reader's comprehension cost rises because every read reconstructs the method's outline from scratch.

Goal

The top of the method reads as a numbered outline of intention-revealing steps at one level of detail; each step's how-it-works lives in a named helper. Readers verify the algorithm at the top level and drill into helpers only when the named step's body is the point of interest, supporting separation of concerns between orchestration and mechanism.

Before the refactoring

function add(item, quantity) {
  if (this.readOnly) throw new Error('list is read-only');
  const existing = this.items.find(line => line.product.id === item.id);
  if (existing) {
    existing.quantity += quantity;
  } else {
    this.items.push({ product: item, quantity });
    this.items.sort((a, b) => a.product.id - b.product.id);
  }
  this.recalculateTotal();
}

After the refactoring

function add(item, quantity) {
  assertWritable(this);
  const existing = findLineFor(this.items, item);
  if (existing) {
    increaseQuantity(existing, quantity);
  } else {
    insertNewLine(this.items, item, quantity);
  }
  this.recalculateTotal();
}

Example source: Illustrative example written for this site, not a quotation from the book. The pattern itself is Joshua Kerievsky's, from Refactoring to Patterns (Addison-Wesley, 2004), see the chapter on Compose Method.

Pressure

Every reader pays the outline-extraction cost on every visit. Small edits to one step force the reader to hold all the others in working memory; the method becomes a churn magnet that touches unrelated changes in the same diff. The team's verification cost compounds across reviewers who must re-derive the method's structure each time.

Tradeoff

Helper methods can scatter logic that was once readable as a single span; over-decomposition produces a fan-out of tiny methods where the actual computation is buried three levels deep. The team's maintenance cost can rise rather than drop if the helpers don't carry domain meaning, because every helper is one more name the reader must look up.

Relief

The method body becomes the algorithm in domain language; details live in helpers whose names tell the reader what they do. Editing one concern stays local to the matching helper. The team's enhancement cost drops because adding a new step is one new helper rather than another interleaved block in an already-cluttered body.

Trap

Compose every method this way and the workflow becomes a forest of one-liners that can no longer be read linearly — the named steps become a directory listing instead of a procedure. The fan-out adds accidental complexity to the call graph; readers carry the cognitive load of jumping between trivial helpers to reconstruct the original procedure.