Single Responsibility Principle: Definition and Core Problem

Definition
Single Responsibility Principle (SRP) states that a class should have only one reason to change, meaning it should have only one job or responsibility. It is the first principle in SOLID and focuses on cohesion within a class.
The Core Problem SRP SolvesWhen a class handles multiple responsibilities, changes to one responsibility can break or affect the others. This creates fragile code where a bug fix in one area introduces bugs in unrelated areas. SRP reduces coupling between unrelated concerns and makes code easier to test and maintain.
What is a "Responsibility"?A responsibility is a reason to change. It represents a business concern or actor in the system. For example, in a Vehicle class, parking logic (facility management concern) and maintenance scheduling (operations concern) are separate responsibilities because they serve different stakeholders and change for different reasons.
Interview Tip: When asked about SRP, always connect it to "reasons to change" rather than "number of methods." A class with 10 methods can still follow SRP if all methods serve the same responsibility.
Common MisconceptionsFirst, SRP does not mean a class should do only one thing or have only one method. A ParkingSpot class can have occupy(), vacate(), and isAvailable() methods because they all serve the single responsibility of managing spot state.
Second, responsibility is not the same as functionality. Validating data, persisting data, and formatting data are three separate responsibilities even though they might all involve the same entity.
Business ImpactSRP directly affects maintainability costs. When responsibilities are mixed, a change request from the accounting department (like fee calculation) might accidentally break parking availability logic (facility management). Separating these concerns isolates changes to their relevant modules.

💡 Key Takeaways

✓SRP means one reason to change, not one method or one function

✓A responsibility represents a business concern or stakeholder who might request changes

✓Violating SRP creates fragile code where unrelated changes cause unexpected bugs

✓SRP improves testability because each class has a focused, clear purpose

📌 Examples

1A Vehicle class that handles parking logic AND maintenance scheduling violates SRP

2A ParkingSpot class with occupy(), vacate(), and isAvailable() follows SRP (all manage spot state)

← Back to Single Responsibility Principle Overview