Single Responsibility Principle (SRP)

The Single Responsibility Principle says a class should have one well-defined reason to change. In Java backend design, SRP helps keep classes focused, easier to test, and less affected by unrelated requirements.

SRP is one of the SOLID principles. A class should concentrate on one cohesive responsibility rather than combining unrelated concerns such as validation, persistence, formatting, and notification logic.

The important phrase is "reason to change." If two parts of a class routinely change for different business or technical reasons, they may belong in separate classes. SRP does not mean every class must contain only one method.

For example, an `OrderService` might coordinate an order workflow, while `OrderValidator` validates input and `OrderRepository` handles database access. Separating these responsibilities makes each component easier to understand and test.

SRP is about cohesion, not simply making classes smaller. Splitting a naturally cohesive responsibility into many tiny classes can make the design harder to follow without providing a real benefit.

In an interview, explain SRP using change boundaries: identify responsibilities, determine which requirements would cause each part to change, and separate responsibilities when those change reasons are independent.

Key points

• A class should have one primary reason to change.
• SRP is about cohesive responsibilities, not one method per class.
• Separate concerns that change for independent reasons.
• Common separations include business logic, persistence, validation, and presentation.
• Avoid excessive fragmentation into meaningless tiny classes.

Interview questions

What is the Single Responsibility Principle?

SRP says that a class should have one cohesive responsibility and therefore one primary reason to change. It does not mean the class can contain only one method. The goal is to keep unrelated concerns from becoming tightly coupled. For example, database access and business validation can be separated when they change independently.

Does SRP mean every class should do only one thing?

Not necessarily. A class can contain several closely related operations that support the same responsibility. SRP is concerned with whether those operations belong to the same change boundary. Splitting every small operation into its own class can create unnecessary complexity.

How would you refactor a class that violates SRP?

First, I would identify the different responsibilities currently mixed together. Then I would group code according to the reasons it changes, such as persistence, validation, and business rules. I would extract those responsibilities into focused collaborators and let the original class coordinate them where appropriate. Finally, I would use tests to verify that behavior remains unchanged.

What are the benefits of SRP in a Java backend application?

SRP can reduce coupling between unrelated concerns and make individual components easier to test. A change to persistence code, for example, is less likely to require modifying validation logic when those responsibilities are separated. It also improves readability because a class has a clearer purpose. The benefit is strongest when the responsibilities genuinely have different change patterns.

Can applying SRP too aggressively hurt a design?

Yes. If every small behavior becomes a separate class, the design can accumulate indirection and make simple workflows difficult to understand. SRP should be applied according to meaningful responsibility and change boundaries rather than a mechanical class-size rule. The appropriate boundary also depends on the domain and the application's complexity.