Skip to main content

Single Responsibility Principle: Reasons to Change

What This Concept Is​

The Single Responsibility Principle (SRP), in Robert Martin's formulation, says:

A class should have one, and only one, reason to change.

The operational word is reason. Responsibility is not a feature, a method, or a line of code. It is a direction from which change pressure arrives: a stakeholder, a policy, or an external system whose evolution can force the class to change.

Independent change pressures suggest a responsibility boundary. Count coherent policy decisions rather than individual people: two stakeholders can share one policy, and one stakeholder can own several independent policies.

Why It Matters Here​

SRP is the class-scope specialization of cohesion. A non-cohesive class has multiple responsibilities; those responsibilities correspond to distinct reasons to change, usually aligned with distinct people or systems that care.

Unrelated policies sharing a module can increase review and regression costs. Use actual changes and failures to test that hypothesis; a merge conflict alone does not diagnose SRP.

Concrete Example​

An Employee class with three reasons to change:

class Employee {
    BigDecimal calculatePay() { /* HR policy */ }
    void save(Connection c)  { /* DBA schema */ }
    String reportHours()      { /* accounting format */ }
}

Three stakeholders: HR, the DBA, and accounting. Three reasons to change. If HR ships a new pay formula, the save method's tests run. If the DBA renames a column, the payroll tests run. Every change is wider than it needs to be.

Candidate separation (declaration sketch, not a compilable Java program):

class Employee { /* domain state only */ }
class PayCalculator   { BigDecimal calculatePay(Employee e); }
class EmployeeRepository { void save(Employee e, Connection c); }
class HoursReport     { String of(Employee e); }

Each class now answers to one stakeholder.

Common Confusion / Misconception​

"SRP means a class should only have one method." No. A class can have many methods as long as they serve one reason to change. A Polynomial with twenty methods has one responsibility: polynomial algebra.

A subtler misconception: "SRP means separate what the code does." SRP is about separating why the code changes. Two methods that both implement pricing rules can live together even if one formats a string and the other sums numbers, because they change for the same reason.

A third misconception: "SRP means one class per file." File layout is not the principle. You can have five cohesive, single-responsibility classes in one file.

How To Use It​

SRP is easiest to apply by asking questions, not by counting methods:

  1. Who will demand changes to this class? Name the actual humans or systems.
  2. If two of those demands arrived at the same time, would both touch the same class?
  3. If yes, what is the axis of variation they share? If there is no shared axis, split along the axes.
  4. Name the resulting capabilities in domain language; no suffix proves that a boundary is useful. A function or module may be sufficient.

Check Yourself​

  1. Why does "reasons to change" measure responsibility better than "things the code does"?
  2. Can a class with one public method still violate SRP? How?
  3. If two responsibilities always change together, have you actually found two responsibilities?

Mini Drill or Application​

Pick a class over 100 lines in a project you know. Do all four:

  1. List every place in the organization (or every external system) that could demand a change to this class.
  2. For each item, say which method would change.
  3. If two distinct sources would change different methods, draw the split line.
  4. Name candidate boundaries and describe one reason to keep the current arrangement.

Read This Only If Stuck​

Engineering extension: Responsibility is a hypothesis about change​

Use a change table: requested behavior, affected decision, invariant, owner and expected tests. Payroll calculation and payslip rendering may evolve separately even if one manager requests both. Conversely, several teams may depend on the same tax policy. Do not split by organization chart alone. Try: argue both sides of extracting a format helper. Check: a useful extraction has a stable input/output contract and removes a concrete source of independent change; a suffix or class count is not evidence.

Use the design contracts and practice feedback after an independent attempt.