Splitting without shattering

SRP is about reasons to change, not about size. The principle is often misquoted as “a class should do one thing,” which invites you to count statements and split until every class has one method. The actual formulation is sharper: a module should have one reason to change — or, equivalently, it should be responsible to one actor. An “actor” is a source of change: a stakeholder, a policy, a protocol that evolves on its own clock.

// Robert Martin's classic example: three actors hiding in one class.
class Employee {
  calculatePay()  { /* changes when the CFO / payroll policy changes */ }
  reportHours()   { /* changes when the COO / ops reporting changes */ }
  save()          { /* changes when the DBA / schema changes */ }
}

These three methods serve three different actors who change for unrelated reasons. That — not the line count — is why Employee should split. The right number of pieces is the number of independent reasons to change, no more and no fewer. Size is a symptom you investigate; it is not the rule itself.

Split when two responsibilities have genuinely independent change cadence. The most reliable signal is observed, not imagined: do these two things change at different times, for different requests? If pricing rules change quarterly with the finance team and the email template changes whenever marketing has a campaign, they are on different clocks. Keeping them in one class means every marketing tweak risks the pricing logic, and every pricing review drags through email markup.

// Different clocks → split. PricingPolicy changes on the finance cadence;
// ReceiptTemplate changes on the marketing cadence. They never move together.
class PricingPolicy   { totalFor(cart: Cart): Money { /* finance owns this */ } }
class ReceiptTemplate { render(order: Order): Html  { /* marketing owns this */ } }

The test is empirical: look at the git history. If two regions of a file appear in commits for different reasons, that is a real seam. Splitting along it means future changes stay local — a finance change touches PricingPolicy only. Splitting across it (a clock you invented) buys nothing and costs indirection.

Keep together what always changes together and shares state. The inverse test is just as important and far more often ignored. Two pieces of logic that always appear in the same commit, that share the same invariants, that read and write the same fields — these are one responsibility wearing two method names. Splitting them scatters a single concept across files and forces every change to hop between them.

// Cohesive: validate and apply both enforce the SAME invariant
// (a balance never goes negative) over the SAME field. They always
// change together. Splitting them into Validator + Applier classes
// would mean the invariant lives in two files that must stay in sync.
class Account {
  #balance: Money;
  withdraw(amount: Money): void {
    if (amount.gt(this.#balance)) throw new InsufficientFunds();
    this.#balance = this.#balance.minus(amount); // same field, same rule
  }
}

When you split this, a change to the overdraft rule now means editing AccountValidator and AccountApplier and keeping them consistent — you manufactured the very shotgun-surgery you were trying to avoid. Connascent logic (things that must change together to stay correct) belongs together. High cohesion is the goal; SRP is just one lever on it.

Class explosion is an SRP failure, not an SRP success. When a split produces classes that have no independent reason to change — a Validator and an Applier that are always edited in the same PR, a Mapper that exists only to move three fields — you have lowered cohesion, not raised it. The cost is real and it is paid on every read: indirection without information. To answer “what does placing an order do?” you now open eight files and hold their interaction in working memory, because the behaviour was shattered across them with no boundary that means anything.

// Over-applied SRP: one cohesive operation atomised into delegating shells.
class OrderValidator    { validate(o: Order) { /* one if */ } }
class OrderPriceApplier { apply(o: Order)    { /* one line, calls Calculator */ } }
class OrderTotaller     { total(o: Order)    { /* one sum */ } }
// placeOrder() now orchestrates seven of these. Reading it is reassembly.

The senior move is to recognise both shapes as the same defect — wrong cohesion — pointing in opposite directions. A god class is many reasons to change crammed into one box; a class explosion is one reason to change smeared across many boxes. Neither maps the module boundary to a real change boundary. SRP done well lands between them: as few modules as the distinct actors require, and no fewer.