What is the Single Responsibility Principle?
Learn the Single Responsibility Principle (SOLID) — one reason to change, common violations — with a Java refactoring example.
Expected Interview Answer
The Single Responsibility Principle states that a class should have only one reason to change, meaning it should own exactly one well-defined responsibility rather than mixing unrelated concerns together.
It is the "S" in SOLID and is often misread as "a class should do only one thing," but the more precise formulation from Robert C. Martin is about a single axis of change: a class should answer to only one actor or stakeholder group. When a class handles multiple unrelated responsibilities, such as business logic plus persistence plus formatting, changes driven by entirely different stakeholders end up forcing edits to the same class, increasing the risk of one change breaking unrelated behavior. Applying SRP typically means extracting the extra responsibilities into their own classes, each with a narrow, well-named purpose, and wiring them together through composition. Overapplying SRP into excessively fine-grained classes has its own cost, so the goal is a sensible-sized single responsibility, not the smallest possible class.
- Isolates changes to the class that actually owns that concern
- Makes classes easier to name, test, and understand in isolation
- Reduces the blast radius of a single code change
- Enables reuse of individual responsibilities independently
AI Mentor Explanation
A wicketkeeper has one clear job — take deliveries and effect stumpings behind the stumps — while bowling, batting order strategy, and ground maintenance are each somebody else’s responsibility entirely. If the keeper were also responsible for setting the batting order and mowing the outfield, a change to any of those unrelated duties would disrupt the same person’s focus. That is the Single Responsibility Principle: one role, one reason to be retrained or reassigned, with unrelated concerns owned by separate specialists.
Step-by-Step Explanation
Step 1
Identify the class’s stakeholders
List which actors or business concerns could each independently request a change.
Step 2
Spot more than one axis of change
If two unrelated stakeholders both drive changes to the same class, SRP is violated.
Step 3
Extract the extra responsibility
Move the unrelated concern into its own class with a clear, narrow purpose.
Step 4
Wire them together via composition
The original class delegates to the extracted class instead of doing the work itself.
What Interviewer Expects
- The precise definition: one reason to change, not literally "one method"
- Awareness of the "one actor/stakeholder" formulation from Robert C. Martin
- A concrete before/after refactoring example
- Recognition that over-splitting classes has its own cost
Common Mistakes
- Reducing SRP to "a class should have only one method"
- Splitting a class so finely that related logic becomes hard to follow across many tiny classes
- Not recognizing that mixing persistence and business logic is a classic SRP violation
- Treating SRP as unrelated to the other SOLID principles instead of foundational to them
Best Answer (HR Friendly)
“The Single Responsibility Principle says a class should have just one reason to change — one job, owned by one group of stakeholders. If a class is doing business logic, saving to a database, and formatting output all at once, changes to any of those concerns end up touching the same class and risk breaking the others. Splitting those responsibilities into separate, focused classes makes the code easier to change safely.”
Code Example
// Before: mixes business logic, persistence, and formatting
class InvoiceBad {
double calculateTotal(double[] items) { /* logic */ return 0; }
void saveToDatabase() { /* persistence concern */ }
String formatAsPdf() { /* formatting concern */ return ""; }
}
// After: each concern in its own class
class Invoice {
double calculateTotal(double[] items) { /* logic */ return 0; }
}
class InvoiceRepository {
void save(Invoice invoice) { /* persistence concern */ }
}
class InvoicePdfFormatter {
String format(Invoice invoice) { /* formatting concern */ return ""; }
}Follow-up Questions
- How is SRP different from just "keep classes small"?
- What does "one reason to change" actually mean in practice?
- Can you give an example of an SRP violation you’ve fixed?
- How does SRP relate to the other SOLID principles like Open/Closed?
MCQ Practice
1. The Single Responsibility Principle is best defined as?
SRP is about a single axis/actor of change, not a literal method count.
2. Which is a classic SRP violation?
Mixing business logic, persistence, and notification concerns in one class violates SRP.
3. SRP is which letter in the SOLID acronym?
SRP is the "S" in SOLID — Single Responsibility Principle.
Flash Cards
SRP in one line? — A class should have only one reason to change.
Who defined the "one actor" formulation? — Robert C. Martin (Uncle Bob).
Classic violation example? — A class mixing business logic, persistence, and formatting.
Risk of over-applying SRP? — Excessively fine-grained classes that are hard to follow together.