Single Responsibility Principle (SRP)

📋 Overview

The Single Responsibility Principle (SRP) is the first of the SOLID principles. It states that a class should have one, and only one, reason to change. In practice, this means a module or class should be responsible to one, and only one, actor or business function. SRP is the primary tool for achieving high cohesion and low coupling.

---

🏗️ Core Principles & Characteristics

• Reason to Change: A "responsibility" is defined as a reason to change. If a class handles both database persistence and business logic, it has two reasons to change.
• Cohesion: SRP encourages "High Cohesion," where the methods and data within a class are closely related to a single purpose.
• Encapsulation: By isolating responsibilities, we encapsulate the logic of a specific business rule, making it easier to swap or modify without side effects.
• Actor-Based Design: Often, responsibilities are tied to "actors" (e.g., the Accounting department vs. the HR department). If one class serves both, their requirements will eventually collide.

---

⚖️ Trade-offs: Pros & Cons

Pros

• Maintainability: Smaller, focused classes are easier to understand and modify.
• Testability: Unit tests become simpler and more focused, as there are fewer edge cases per class.
• Reduced Fragility: Changes in one area (e.g., UI layout) are less likely to break unrelated areas (e.g., database logic).
• Reusability: A class that does one thing well is much easier to reuse in other parts of the system.

Cons

• Class Explosion: Over-applying SRP can lead to a massive number of tiny classes, which can increase navigation complexity.
• Fragmentation: Business logic that was once in one place may now be spread across five classes, requiring better orchestration.

---

🌍 Real-World Implementation

• Service Layer Pattern: Splitting a UserService into UserAuthenticationService, UserProfileService, and UserPersistenceService.
• Report Generation: Having a ReportDataCollector class, a ReportFormatter (PDF/Excel) class, and a ReportDelivery (Email/S3) class.
• Logging: Not putting logging logic inside business classes, but using Interceptors or AOP (Aspect Oriented Programming) to handle it separately.

---

💡 Interview "Gotchas" & Tips

• The "God Class" Trap: Mention that the opposite of SRP is the "God Object"—a class that knows too much or does too much.
• Business Reason vs. Method Reason: Emphasize that SRP is about business reasons to change, not just counting the number of methods.
• Collaboration: Explain that SRP doesn't mean a class works in isolation; it means it delegates other responsibilities to other specialized classes.
• DRY vs. SRP: Sometimes developers violate SRP to stay DRY (Don't Repeat Yourself). Explain that "accidental duplication" (two things look the same but change for different reasons) is better than a "unified" class that violates SRP.

---

📐 Suggested Architecture Primitives

• Delegation Pattern: A class delegates specialized tasks to helper classes.
• Strategy Pattern: To encapsulate different algorithms or behaviors that might change independently.
• Facade Pattern: To provide a single entry point to a group of classes that each follow SRP.
• Dependency Injection: To manage the orchestration of many small, single-responsibility classes.