Overview
The Single Responsibility Principle (SRP) says a class should have only one reason to change. A reason to change is a stakeholder or concern: business rules, persistence, formatting, and notification are different concerns.
SRP is not about a class having one method. It is about cohesion: everything in the class should change for the same reason, so a change for one concern cannot accidentally break another.
The chef cooks, the cashier takes payment, and the server delivers food. If the cashier changes the payment system, the chef's recipes are unaffected. One person doing all three jobs means any change disrupts everything.
When to use it
- A class name includes And or Manager and does many unrelated things.
- Changing an email template requires editing the same class that calculates invoices.
- Unit tests need a database, SMTP server, and file system just to test business logic.
- Different teams frequently edit the same file for unrelated reasons.
Where it shows up in interviews
Recognize it when: Manager/Service class doing everything.
- Refactor an OrderManager
- Design an invoice system
Recognize it when: 'what is wrong with this class?'
- Review a UserService that validates, saves, and emails
Where it is used in real software
Controllers, services, and repositories each change for different reasons.
Small programs that do one thing well (grep, sort, wc) are SRP at the tool level.
Each service owns one business capability, the same principle at system scale.
Key terms
- Responsibility
- A reason to change, tied to one actor or concern.
- Cohesion
- How closely the members of a class belong together.
- Coupling
- How much one class depends on others' details.
How to apply it
- 1List the reasons to change
Ask who would request changes to this class: finance, operations, marketing, the DBA?
- 2Group members by reason
Methods and fields that change together stay together.
- 3Extract each group
Create focused classes: InvoiceCalculator, InvoiceRepository, InvoiceEmailer.
- 4Coordinate with a thin service
A small application service calls each class in order without containing their logic.
Splitting an Invoice class
An Invoice class calculates totals, saves to a database, and emails the customer
| Responsibility | Changes when | New class |
|---|---|---|
| Tax and totals | Tax rules change | InvoiceCalculator |
| Persistence | Database or schema changes | InvoiceRepository |
| Template or provider changes | InvoiceNotifier | |
| Orchestration | Workflow order changes | InvoiceService |
NOWResponsibility: Tax and totals | Changes when: Tax rules change | New class: InvoiceCalculator
Each class can now be tested alone. Swapping the email provider touches only InvoiceNotifier.
Implementation
// Three reasons to change in one class.class Invoice { constructor(public items: LineItem[], public customerEmail: string) {} total(): number { const subtotal = this.items.reduce((sum, item) => sum + item.price * item.qty, 0); return subtotal * 1.18; // tax rule } save(): void { db.query("INSERT INTO invoices ...", [this.total()]); // persistence } email(): void { smtp.send(this.customerEmail, `Your total is ${this.total()}`); // notification }}Complexity and performance
Each focused on one concern.
Pure logic tests need no infrastructure.
Trade-offs
Splitting every method into its own class scatters logic and hurts readability. Split along real change boundaries, not line counts.
More classes mean more files to navigate. Good names and a thin orchestrating service keep the flow readable.
Variants and related techniques
The same idea applies to packages and services: a service should own one business capability.
SRP is SoC applied to classes.
Common mistakes
- Interpreting SRP as one method per class.
Fix: Focus on one reason to change, which can involve many methods.
- God classes named Manager, Helper, or Utils.
Fix: Name classes after one responsibility; vague names signal mixed concerns.
Interview questions
How do you identify SRP violations?
Ask how many different actors could request a change to the class. If finance and marketing both edit it, it has at least two responsibilities.
Does SRP increase the number of classes?
Yes, but each is smaller, easier to test, and safer to change. The goal is lower risk per change, not fewer files.
Practice problems
| Problem | Difficulty | What it trains |
|---|---|---|
| Refactor a UserManager | Easy | Split validation, persistence, and email. |
| Report generator | Medium | Separate data fetching, formatting, and export. |