# Single Responsibility Principle (SRP) The **Single Responsibility Principle (SRP)** is the "S" in [[SOLID Principles]]. The most-quoted version — "a class should have one reason to change" — is [[Robert C. Martin]]'s. His later, more careful formulation: **"a module should be responsible to one, and only one, actor."** An *actor* is a stakeholder, role, or source of change requests. The principle is about *change*, not size. A class with three small methods can violate SRP if each method serves a different actor. A class with thirty methods can satisfy SRP if all of them serve the same actor and change together. ## Why "reason to change" matters If the same module serves two actors, a request from one actor forces edits that risk breaking the other. The module is now a coordination point between unrelated stakeholders. Symptoms: - Pull requests touching a class for unrelated reasons in the same week. - Tests for one feature breaking when another feature changes. - Two engineers fighting over the same file for unrelated work. - "Just one more parameter" creeping into a method whose original signature was clean. The actors-based formulation gives you a concrete diagnostic: *who would request this change?* If the answers diverge, the responsibilities have diverged. ## Cohesion as the SRP heuristic A module satisfies SRP when its methods, fields, and dependencies are *cohesive* — they exist to serve the same purpose. SRP is the [[High Cohesion]] principle viewed through the lens of *change*. Tells of low cohesion (and likely SRP violation): - The class name is vague (`UserManager`, `DataHelper`, `CommonUtils`). - A subset of methods uses a subset of fields; another subset uses different fields. The class is two classes glued together. - Different methods need different test setups; mocks barely overlap. - Importing the module pulls in transitive dependencies you don't need for the slice of behavior you wanted. ## SRP and atomic notes The same logic applies in PKM: an atomic note serves one idea — one *reason to change*. A note that mixes three ideas forces unrelated edits to the same file, breaks reuse, and dilutes the idea. SRP is the software-engineering name for the same discipline. See [[Atomicity]] and [[Connectability is the primary atomicity heuristic]]. ## What SRP is NOT - **NOT "do only one thing."** A class can do many things if they're all in service of the same responsibility. - **NOT "have only one method."** A repository class with `find`, `save`, `delete`, and `query` for one entity is fine. - **NOT a size limit.** A 50-line class with two responsibilities violates SRP; a 400-line class with one cohesive responsibility may not. - **NOT specific to classes.** SRP applies to functions, modules, services, packages, microservices — any unit of code. ## Common refactorings to restore SRP - **Extract Class** — when methods cluster around different fields. - **Extract Method to its own module** — when an unrelated procedural step lives inside a class that's otherwise cohesive. - **Split by actor** — Martin's example: a `Employee` class with `calculatePay()` (Finance), `reportHours()` (HR), and `save()` (DBAs) is one class serving three actors. Split into three. - **Facade** — if callers need a unified surface, a thin facade can wrap the split classes without re-merging the responsibilities. ## Tradeoff: don't over-split Splitting too aggressively produces *anemic* classes — many tiny modules with shallow logic, scattered across the project, hard to navigate. SRP is a heuristic for finding *seams between actors*, not a directive to maximize the number of files. The right granularity is the one where the actors are clearly separated and each class's purpose is summarizable in one phrase. ## References - Robert C. Martin — *Clean Architecture* (2017), Chapter 7 (the actor-based formulation) - Robert C. Martin — *Agile Software Development: Principles, Patterns, and Practices* (2002), Chapter 8 ## Related - [[SOLID Principles]] - [[Open Closed Principle (OCP)]] - [[Liskov Substitution Principle (LSP)]] - [[Dependency Inversion Principle (DIP)]] - [[High Cohesion]] - [[Loose Coupling]] - [[Atomicity]] - [[Composition over Inheritance]] - [[Robert C. Martin]]