Single Responsibility: One Reason to Change, One Owner

A Marketing manager asked to soften the wording of the OTP message. One-line change. It shipped — and Compliance’s nightly audit export broke, because the audit format and the message copy lived in the same 600-line NotificationService. Nobody who reviewed the copy change knew the audit parser depended on it.

See the collision

Pick an actor and watch the blast radius of their change. In one class, everyone’s change threatens everyone else’s. Split it, and each change stays home.

Pick an actor to see the blast radius

NotificationService

format()send()retry()audit()persist()

The refactor

The NotificationService you met in the hub — every responsibility fused into one class:

Before: one class, five actors

Split by actor: five focused classes, plus a thin coordinator whose only job is orchestration.

After: one class per reason to change

Finding the seams

In the wild

Tradeoffs

Splitting by actor buys

Changes stay contained — one actor, one class, no collateral damage
Each class is trivially unit-testable in isolation
Teams edit different classes in parallel without merge collisions

But it costs

More classes and a coordinator to wire them
Over-splitting creates anemic classes and shotgun surgery
You must actually know who the actors are — guess wrong and the seams are wrong

Interview corner

Coding challengeName the actors, then split

Medium

This class fails SRP. List the distinct actors it serves, then sketch the split.

class UserProfileService {
    boolean isValidEmail(String email) { /* validation rules — Product */ }
    void save(User user) { /* SQL — DBA */ }
    void sendWelcomeEmail(User user) { /* SMTP + copy — Marketing */ }
    String renderProfileCard(User user) { /* HTML — Design */ }
}

Lock it in

References

Robert C. Martin — The Single Responsibility Principle (article) and Clean Architecture (2017), where SRP is defined in terms of a single actor.
Robert C. Martin — Agile Software Development, Principles, Patterns, and Practices (2002), the Employee/payroll example.
M. D. McIlroy et al. — the Unix philosophy, “do one thing and do it well.”