Single Responsibility Principle
The software design principle stating that a module, class, or function should have one and only one reason to change, keeping it focused on a single concern.
Also known as: SRP, Single Responsibility, One Reason to Change
Category: Software Development
Tags: software-development, principles, design-patterns, architecture, clean-code
Explanation
The Single Responsibility Principle (SRP) is the first of the five SOLID principles of object-oriented design, articulated by Robert C. Martin (Uncle Bob). It states: 'A module should have one, and only one, reason to change.' This means each unit of code should be responsible to one, and only one, actor or stakeholder.
## What 'Responsibility' Means
A common misunderstanding is that SRP means 'a class should do only one thing.' Martin's actual definition is more nuanced: a responsibility is a reason to change. If a class could be modified for two different reasons — say, both business logic changes and formatting changes — it has two responsibilities and should be split.
The key question is not 'does this class do one thing?' but 'who would request changes to this class?' If different stakeholders would request different kinds of changes, the class has multiple responsibilities.
## Why SRP Matters
### Reduced coupling
When a module has a single responsibility, changes to one area of the system don't unexpectedly affect unrelated areas.
### Improved testability
Modules with a single responsibility are easier to test because they have fewer dependencies and clearer expected behavior.
### Better readability
A module focused on one concern is easier to understand, name, and reason about.
### Easier maintenance
When a bug is reported or a feature requested, you know exactly which module to change and can be confident the change won't break something unrelated.
### Parallel development
Teams can work on different responsibilities independently without stepping on each other's code.
## Examples
### Violation
```
class Employee {
calculatePay() // Accounting department
generateReport() // Reporting department
saveToDatabase() // IT/DBA team
}
```
Three different stakeholders, three reasons to change.
### Applied
```
class PayCalculator { calculatePay() }
class ReportGenerator { generateReport() }
class EmployeeRepository { save() }
```
Each class has one stakeholder and one reason to change.
## SRP Beyond Code
The principle applies broadly:
- **Functions**: Each function should do one thing at one level of abstraction
- **Microservices**: Each service should own one business capability
- **Teams**: Two-pizza teams work best when each owns a single area (Conway's Law)
- **Documents**: Each document should serve one purpose for one audience
- **Meetings**: Effective meetings have a single clear objective
## Connection to Unix Philosophy
SRP echoes the Unix philosophy of 'do one thing and do it well.' Unix tools like `grep`, `sort`, and `wc` each handle a single task excellently, and composition (piping) combines them for complex workflows. This is SRP in action at the system level.
## Common Mistakes
- **Over-splitting**: Creating too many tiny classes that are hard to navigate. SRP doesn't mean every method needs its own class
- **God classes**: The opposite extreme — classes that accumulate every responsibility in their domain
- **Confusing SRP with single method**: A class can have multiple methods and still have a single responsibility
- **Ignoring the 'reason to change' test**: Splitting by technical layer rather than by stakeholder often misapplies SRP
Related Concepts
← Back to all concepts