SRP vs Coupling Cohesion Separation of Concerns

SRP, coupling, cohesion, and Separation of Concerns are not four interchangeable slogans — they are one cause and three measurable effects: SRP is the design rule ("one axis of change per module"), and when you obey it the responsibilities a class names shrink, which mechanically pulls cohesion up (the methods now all touch the same data), pulls coupling down (each class names fewer collaborators), and produces Separation of Concerns at the system level (each concern lives in exactly one place). The other three are the dials you read off a class to check whether you actually achieved SRP.

The four definitions, sharpened

The key distinction the old page glossed over: SRP is per-module and intent-level; SoC is system-level and structural; cohesion/coupling are the metrics that fall out. Uncle Bob's precise phrasing of SRP is not "do one thing" — it is "a module should have one, and only one, reason to change," i.e. it should answer to a single actor (stakeholder role). That actor framing is what makes the worked example below split the way it does.

One class, traced through all four

Here is a god-class that violates SRP. Watch what each metric reads before the fix.

// BEFORE: one class, three actors
class OrderProcessor {
    // --- pricing concern (owner: Finance) ---
    double subtotal(List<Item> items) {
        double s = 0;
        for (Item i : items) s += i.price * i.qty;
        return s;
    }
    double withTax(double subtotal) { return subtotal * 1.18; } // 18% GST

    // --- persistence concern (owner: DBA) ---
    void save(Order o) {
        String sql = "INSERT INTO orders(id,total) VALUES(" + o.id + "," + o.total + ")";
        jdbc.execute(sql);   // raw JDBC string
    }

    // --- notification concern (owner: Marketing) ---
    void emailReceipt(Order o) {
        smtp.send(o.customerEmail, "Receipt #" + o.id, renderHtml(o));
    }

    Order process(List<Item> items, String email) {
        double total = withTax(subtotal(items));
        Order o = new Order(nextId(), total, email);
        save(o);
        emailReceipt(o);
        return o;
    }
}

Now read the dials on OrderProcessor as written:

Apply SRP — split by actor, then re-read the dials

// AFTER: split by reason-to-change (actor)
class PricingService {                 // actor: Finance
    double total(List<Item> items) {
        double s = 0;
        for (Item i : items) s += i.price * i.qty;
        return s * 1.18;               // GST lives in ONE place now
    }
}

interface OrderRepository {            // actor: DBA owns the impl
    void save(Order o);
}

interface ReceiptSender {              // actor: Marketing owns the impl
    void send(Order o);
}

class OrderProcessor {                 // actor: order-flow / use-case owner
    private final PricingService pricing;
    private final OrderRepository repo;
    private final ReceiptSender receipts;

    OrderProcessor(PricingService p, OrderRepository r, ReceiptSender s) {
        this.pricing = p; this.repo = r; this.receipts = s;
    }

    Order process(List<Item> items, String email) {
        double total = pricing.total(items);
        Order o = new Order(nextId(), total, email);
        repo.save(o);
        receipts.send(o);
        return o;
    }
}

The same trace, re-measured. Note that OrderProcessor still depends on three things — but now through interfaces it does not own, which is the difference between brittle and stable coupling:

Why the naive version is not just "ugly" but wrong: in the before-class, a Marketing request to change the receipt HTML forces a recompile and redeploy of the code that computes money. The two have no logical reason to ship together; coupling them means a templating typo can block a pricing hotfix. SRP's "one actor" test predicts exactly this collision before it happens.

Pitfalls

• "One method = one responsibility." SRP is about reasons to change (actors), not verb count. A class with twenty methods that all serve the Finance team has one responsibility; a class with two methods serving two teams has two. Splitting by method count produces anaemic, over-fragmented classes.
• Mistaking low coupling for the goal and over-abstracting. Introducing an interface for every collaborator to "reduce coupling" when there is only ever one implementation adds indirection with no payoff — you trade readable, traceable code for a maze of one-method interfaces. Coupling is a symptom to watch, not a number to minimise blindly.
• High cohesion ≠ SRP automatically. A class can be tightly cohesive (all methods touch the same fields) yet still serve two actors — e.g. a User class whose fields back both authentication logic and profile-rendering logic. Cohesion passes; SRP still fails. Always run the actor test, not just the field-sharing test.
• Splitting too early. Applying SRP to a 30-line script before you know which parts change independently invents seams you'll fight later. Wait for the second reason-to-change to actually arrive (the Rule of Three), then split along the observed fault line.
• SoC across the wrong axis. Separating "all the controllers / all the services / all the repos" into layers looks like SoC but smears a single feature across three folders — a feature change touches all three. Concern boundaries should follow change-axes, not technical-layer labels.
• Know the two smells by name. An SRP violation shows up as one of Fowler's two mirror-image smells: divergent change (one class edited for many different reasons — too many actors in one module) and shotgun surgery (one conceptual change forces edits across many classes — one actor's concern smeared everywhere). The cheap metric that catches both: count the files touched per feature/change-request; a healthy module changes for one reason and a feature changes one module.

When to lean on each lens (and when not to)

These are not alternatives you choose between — they are different instruments you reach for at different moments. The senior skill is knowing which one answers the question in front of you.

Concrete decision, the GST scenario: Finance asks to change 18% → 12%. With the before-class you'd open the 200-line OrderProcessor, find the magic 1.18 buried in withTax, and redeploy code that also sends emails. Applying the SRP actor test predicted this pain, so you'd already have split PricingService — now the change is a one-line edit in a class no email or DB code can break. Choose to split when a second actor appears; prefer to keep it inline when only one actor has ever touched the code.

Takeaways

• SRP is the cause; cohesion, coupling, and SoC are the effects you measure. Obeying "one actor per module" mechanically raises cohesion, lowers coupling, and yields SoC.
• SRP and SoC differ in scope: SRP is per-module and intent-driven ("one reason to change"); SoC is system-wide and structural ("each concern in one place"). Applying SRP everywhere is how you achieve SoC.
• Run the actor test, not the verb-count test. Count the distinct stakeholders who could demand a change; that number is your responsibility count.
• Don't minimise coupling blindly. Abstractions cost indirection — introduce them where a real second implementation or a test seam exists, not preemptively.

Sources: Robert C. Martin, Clean Architecture (2017), ch. 7 — the "single actor / one reason to change" formulation of SRP; Martin's original "SRP" article and the SOLID papers (objectmentor.com); Edsger Dijkstra, "On the role of scientific thought" (1974) — origin of Separation of Concerns; Yourdon & Constantine, Structured Design (1979) — the coupling/cohesion spectrum and LCOM intuition. Worked OrderProcessor example and metric trace authored for this guide. Re-authored and deepened for this guide — replaced bare compare-and-contrast bullets with a single class traced through all four lenses before and after refactoring.