Introduction to the Single Responsibility Principle

Single Responsibility Principle (SRP)

SRP works by aligning each module with exactly one source of change — one group of people (an “actor”) who can request modifications — so that a request from one stakeholder can never force an edit that risks breaking another stakeholder's behavior.

Robert C. Martin's precise statement is the one to memorize, because the popular paraphrases are wrong:

“A module should have one, and only one, reason to change.” — and a “reason to change” means one actor: a single source of requirements (a role, a department, a stakeholder).

Note what SRP is not saying. It is not “a class should do only one thing” — a class can have many methods. It is not about how many features a tool has (the old multitool-vs-knife analogy conflates “does many things” with “serves many masters”; a Swiss Army knife with one owner has one reason to change). SRP is about who can demand a change. A class with twenty methods all answerable to a single team is fine; a class with two methods answerable to two different teams is a violation.

A concrete violation: the classic Employee class

Martin's own example. One class accidentally serves three different actors. Watch how a change requested by one of them silently breaks another.

// VIOLATION — three actors, one class
class Employee {
    double calculatePay()    { /* used by Finance     */ }
    String reportHours()     { /* used by HR / Ops     */ }
    void   save()            { /* used by DBAs / Tech  */ }

    // helper shared by calculatePay() AND reportHours()
    private double regularHours() { /* ... */ }
}

The three public methods answer to three distinct actors with three distinct “reasons to change”:

The failure traced step by step

Both calculatePay() and reportHours() call the shared private helper regularHours(). Trace a single Finance request with real numbers:

1. Start state. An employee works 45 hours. regularHours() returns 40 (capping regular hours at 40). Finance pays 40 × $50 + 5 × $75 = $2,375. HR's reportHours() reports 40 regular hours to Operations. Both are correct today.
2. Finance files a request. CFO: “Treat the regular-hours cap as 45 for a new salaried tier.” A developer edits the shared regularHours() to return 45. Pay recomputes to 45 × $50 = $2,250. Finance is happy. Tests for pay pass.
3. The silent break. reportHours() also calls regularHours(). It now reports 45 regular hours to Operations — but HR never asked for this and has no test guarding it. Operations' overtime dashboards, headcount-planning, and compliance reports are now wrong, and nobody noticed because the change was filed and reviewed as a pay change.
4. Why it's insidious. Two actors were coupled through one method. The reviewer who approved a Finance PR had no reason to think about HR. This is exactly the “unexpected duplication / accidental coupling” SRP exists to prevent.

The fix and why the naive version was wrong

The naive class was wrong not because it “did three things” but because it forced three actors to share one editable surface — the private helper became a hidden coupling channel. Separate the three responsibilities so each class answers to exactly one actor, and let them share immutable data only:

// FIX — each class has ONE reason to change
final class EmployeeData {            // plain immutable data, no behavior
    final int    id;
    final double hourlyRate;
    final int    hoursWorked;
    EmployeeData(int id, double hourlyRate, int hoursWorked) {
        this.id = id; this.hourlyRate = hourlyRate; this.hoursWorked = hoursWorked;
    }
}

class PayCalculator {                 // changes only when FINANCE asks
    private static final int REGULAR_CAP = 40;
    double calculatePay(EmployeeData e) {
        int regular  = Math.min(e.hoursWorked, REGULAR_CAP);
        int overtime = Math.max(0, e.hoursWorked - REGULAR_CAP);
        return regular * e.hourlyRate + overtime * e.hourlyRate * 1.5;
    }
}

class HourReporter {                  // changes only when HR / OPS asks
    private static final int REGULAR_CAP = 40;
    int reportHours(EmployeeData e) { return Math.min(e.hoursWorked, REGULAR_CAP); }
}

class EmployeeRepository {            // changes only when DBAs / TECH ask
    void save(EmployeeData e) { /* persist */ }
}

Now the Finance request from the trace edits PayCalculator.REGULAR_CAP only. HourReporter is a different file, owned by a different team, with its own cap and its own tests. The leak path is gone. (The two caps look duplicated — but that is intentional: they are coincidentally equal today and change for different reasons. Collapsing them back into one shared constant would re-introduce the exact coupling we just removed. SRP deliberately tolerates this kind of duplication.)

Pitfalls

• The “one thing” trap → over-splitting. Reading SRP as “one method per class” explodes the design into hundreds of anemic one-method classes. You trade accidental coupling for navigational chaos and dependency wiring overhead. The test is the actor, not the verb count.
• Over-eager DRY. The single most common SRP violation in real code is “helpfully” extracting a shared helper used by two actors — exactly the regularHours() mistake. Two pieces of code that look identical but answer to different stakeholders must stay separate. DRY applies to one reason-to-change, not across them.
• Confusing layers with actors. Splitting by technical layer (controller / service / repo) is orthogonal to SRP. A single “service” can still serve Finance and HR. Ask who files the change ticket, not which tier the code sits in.
• Vague responsibility names. If you can only describe a class's responsibility with “and” (“it manages users and sends email”) or with a god-word like Manager / Processor / Helper, it is almost certainly serving multiple actors.
• Anemic-domain over-correction. Pushing all behavior out of data objects so they hold only fields can scatter logic that genuinely belongs together. SRP separates by reason-to-change, not by “data here, behavior there” dogma.

When to apply SRP — and when not to

Decision signals that point you here: a class is edited by PRs from two different teams; a single “reason” change keeps forcing merge conflicts; you struggle to name the class without “and”; the same file appears in commits tagged for unrelated features; a bug in one feature surfaces in an unrelated one (a coupling smell).

When NOT to split aggressively: early-stage / exploratory code where the actors aren't known yet, small scripts, or stable code that genuinely has one owner. Premature splitting locks in boundaries you'll guess wrong — and the wrong boundary is more expensive than a temporarily fat class.

SRP vs. alternatives

• vs. a single cohesive class (no split). Gain: changes from different actors stop colliding; reviews stay scoped; blast radius shrinks. Cost: more classes, more files to navigate, and orchestration code (a Facade or service) to recombine the pieces — plus tolerated duplication. Choose SRP when two or more distinct actors edit the same code; keep one class when a single owner controls all of it and the methods are cohesive.
• vs. the God Object (the natural drift). A God Object is the limit of ignoring SRP: every actor edits it, every change risks everything, tests become impossible to isolate. SRP is the deliberate force that resists that drift.
• vs. Facade as the recombiner. After splitting, a thin Facade (e.g. EmployeeService) can offer callers a single entry point over the three classes. Gain: SRP-clean internals with a simple external surface. Cost: one extra indirection layer. The Facade itself has one reason to change — the orchestration sequence — which keeps it SRP-clean too.

One-liner: Choose SRP when more than one actor edits the same module; prefer a single cohesive class when one owner controls all of it and splitting would only scatter tightly-related logic.

Takeaways

• SRP = one reason to change = one actor. Not “does one thing,” and not about feature count — it's about who can demand a change.
• The danger SRP prevents is accidental coupling: a shared helper or field that lets a change requested by one stakeholder silently break another's behavior.
• The fix is to split by stakeholder and share only immutable data; SRP deliberately tolerates duplication between code that changes for different reasons.
• Identify violations by the “and” test, by god-words like Manager, and by tracking which teams' PRs touch the file — not by counting methods.

Sources: Robert C. Martin, “Clean Architecture” (2017), Ch. 7 — the canonical “one reason to change / one actor” formulation and the Employee example traced above; Robert C. Martin, “Agile Software Development: Principles, Patterns, and Practices” (2002); Martin's blog post “The Single Responsibility Principle” (2014), which corrects the common “one job” misreading. Re-authored and deepened for this guide: replaced the imprecise “one job” gloss and the army-knife-vs-knife analogy (which conflated multifunction-ness with reasons-to-change) with the actor-based definition, a numbered worked trace, compiling Java, a mechanism diagram, pitfalls, and selection trade-offs.