One reason to change

SRP is about one reason to change, not one thing done. Robert Martin’s own correction is blunt: the principle was never “a module should do one thing.” That folk version is what most people remember, and it’s why SRP gets argued about endlessly — “does parsing and validating count as one thing or two?” has no answer. The actual statement is: a module should have one, and only one, reason to change. A “reason to change” is not a feature or a method; it is a source of requirements — a person or role who can walk in and demand the behaviour be different.

// "Does this do one thing?" — unanswerable, and the wrong question.
// "Who can ask me to change this?" — answerable, and the right one.

The shift from counting verbs to identifying requesters is the whole lesson.

A “reason to change” is an actor. Martin sharpens “reason to change” into actor: the group of users or stakeholders for whom a given change is made. Finance defines how pay is computed. HR defines what counts as reportable hours. The DBA team defines the persistence schema. Each is a separate actor with separate requirements that drift on their own schedule. The canonical violation is one class serving all three:

class Employee {
  calculatePay(): Money { /* Finance owns this rule */ }
  reportHours(): Hours { /* HR owns this rule */ }
  save(): void      { /* DBA owns this schema */ }
}

Three actors. Three reasons to change. SRP says: a module answerable to three actors is three responsibilities wearing one name.

The danger isn’t ugliness — it’s accidental coupling between actors. The reason this is a principle and not a style note is the failure mode it prevents. When two actors share a class, they tend to share private helpers, and a change requested by one actor silently alters behaviour the other actor depends on.

class Employee {
  // Both pay and the HR report call this. Finance "owns" it conceptually.
  private regularHours(): Hours { /* shared helper */ }

  calculatePay(): Money { return rate.times(this.regularHours()); }  // Finance
  reportHours(): Hours  { return this.regularHours(); }              // HR reads the SAME helper
}

Finance asks to change how regularHours() rounds, for payroll reasons. You make the edit. HR’s report — which had no reason to change — now reports different numbers. Nobody asked for that. That is the catastrophe SRP guards against: a Finance requirement reaching out and breaking an HR feature because they were welded together. The coupling is invisible until it ships a wrong report.

Split by actor: one module per source of requirements. The fix is not “make each method its own class.” It is to separate the data from the actor-specific behaviours, so each policy lives with the actor who owns it and changes only when that actor changes.

class EmployeeData { /* just the fields; no business rules */ }

class PayCalculator   { calculatePay(e: EmployeeData): Money { /* Finance only */ } }
class HoursReporter   { reportHours(e: EmployeeData): Hours  { /* HR only */ } }
class EmployeeRepository { save(e: EmployeeData): void { /* DBA only */ } }

Now a Finance change touches PayCalculator and stops there. If pay and reporting genuinely need the same “regular hours” computation, that shared logic must be moved deliberately into its own owned place — not left as a private helper two actors happen to call. The test for “is this one responsibility?” is: could two different actors request conflicting changes to it? If yes, it’s at least two responsibilities, regardless of how few methods it has.