Long method, large class

Bloaters are cohesion decay, not a size problem. “Cohesion” is how strongly the parts of a unit belong together — how single its purpose is. A long method or large class is what low cohesion looks like once it has run for a while: every new requirement got bolted onto the nearest existing place instead of its own, so unrelated concerns now share one scope. The length is the symptom; the disease is that several responsibilities are tangled into one unit.

That reframing matters because it tells you where to cut. If the problem were size, you would split at the midpoint. Because the problem is mixed responsibilities, you split where responsibilities change — even if that leaves one piece at 80 lines and another at 8. The seam, not the line count, is the target.

Learn the detection signals — they fire before the code is unmanageable. You do not need a line threshold; you need to notice the smell early. The reliable signals:

// Signal 1: you scroll to read one logical unit (it doesn't fit on a screen)
// Signal 2: "and" hides in the name → two jobs in one
function validateAndPersistAndNotify(order: Order) { /* ... */ }

// Signal 3: a class hoards instance fields that few methods share
class OrderService {
  private db; private mailer; private taxRates; private inventory;
  private pdfRenderer; private analytics; private retryPolicy;
  // 7 collaborators → it is at least 7 things
}

// Signal 4: deep nesting — blocks 4+ levels in mean hidden sub-procedures
if (a) { for (const x of xs) { if (b) { try { /* ... */ } catch {} } } }

A name with “and”, a method you must scroll, a class with many loosely-shared fields, and arrow-shaped nesting are not style nits. Each says a smaller, named unit is hiding in here — the field clusters and the nested blocks are literally pointing at the seams.

Extract method: give every block a name, and the handler becomes a story. The cure for a long method is to replace each chunk-with-a-purpose with a call to a well-named function. The senior move is that the names form a readable summary — after extraction the top-level method should read like a table of contents, not like an implementation.

// before: one wall, you read line-by-line to learn what it does
function checkout(cart: Cart, user: User) {
  // ...40 lines of validation...
  // ...30 lines of pricing...
  // ...25 lines of payment...
  // ...20 lines of fulfilment...
}

// after: the body is the narrative; detail moves down a level
function checkout(cart: Cart, user: User) {
  validate(cart, user);
  const price = priceOf(cart, user);
  const charge = chargePayment(user, price);
  fulfil(cart, charge);
}

You haven’t deleted complexity — validate still does the work. But you have layered it: the reader who wants the shape reads four lines; the reader chasing a bug in pricing opens priceOf and ignores the rest. Comprehension cost now scales with the question being asked, not with the whole method.

Extract class: when fields cluster, a second object is asking to exist. A large class is usually two or three classes wearing one name. The tell is in Step 2’s signal 3: if half the fields and the methods that touch them concern tax, and the other half concern email, those are two cohesive subsets sharing a scope by accident. Extract the cluster into its own class and let the original delegate.

// before: OrderService knows tax math AND email formatting AND analytics
class OrderService { /* taxRates, mailer, templates, analytics, ...  */ }

// after: each responsibility is its own cohesive unit
class TaxCalculator { taxFor(amount: number, region: Region): number { /* ... */ } }
class OrderMailer   { sendConfirmation(order: Order): void { /* ... */ } }

class OrderService {
  constructor(private tax: TaxCalculator, private mailer: OrderMailer) {}
  place(order: Order) {
    const total = this.tax.taxFor(order.subtotal, order.region) + order.subtotal;
    this.mailer.sendConfirmation({ ...order, total });
  }
}

Now a tax-rule change touches TaxCalculator and nothing else; the email team works in OrderMailer without reading tax code. The blast radius of each likely change collapsed to one cohesive unit — which is the whole economic point of breaking the bloater up.

The failure mode: shattering, not extracting. The amateur reading of “split long methods” is make everything short. So a 200-line method becomes twenty one-line methods — step1, step2, doThing, doThingHelper — and now you trace twenty hops to follow one flow, with no conceptual level you can stop at. You moved the complexity into the call graph; you did not reduce it. Worse, fragments that share no responsibility now masquerade as siblings, which actively misleads the next reader.

The discipline that prevents this: every extracted unit must name a responsibility a domain person would recognise — validate, priceOf, chargePayment — not a position in the original file. If you cannot give the chunk an honest, single-purpose name, you have found a piece of code that does not yet correspond to one idea, and slicing it just hides that. Cut along seams that mean something. When no real seam exists, leaving a cohesive 60-line method intact beats fragmenting it into noise.