✅ Definition: A class should have only one responsibility, and therefore only one reason to change.
In simple words: One Class = One Job = One Reason to Change
🏗️ Architecture Diagram
❌ SRP Violation
💡 Too many responsibilities.
✅ SRP Applied
🌍 Real-world Examples
Example 1 – Employee
❌ Bad
Employee
│
├── CalculateSalary()
├── SaveToDatabase()
├── SendEmail()
└── GenerateReport()
💡 Too many responsibilities.
✅ Good
Employee
│
├── SalaryCalculator
├── EmployeeRepository
├── EmailService
└── ReportService
Example 2 – Banking
❌ Instead of
BankService
│
├── Transfer Money
├── Send SMS
├── Print Receipt
└── Write Logs
💡 Too many responsibilities.
✅ Create
BankService
│
├── TransactionService
├── NotificationService
├── ReceiptService
└── LoggerService
Example 3 – E-Commerce
❌ Instead of
OrderService
│
├── Place Order
├── Process Payment
├── Send Email
└── Generate Invoice
💡 Too many responsibilities.
✅ Create
OrderService
│
├── OrderService
├── PaymentService
├── EmailService
└── InvoiceService
🔑 Important Keywords
- One Responsibility
- One Reason to Change
- High Cohesion
- Separation of Concerns (SoC)
- Maintainability
- Loose Coupling
- Testability
- Modular Design
- Readability
- Reusability
[[PARAGRAPH_INTRO_2]]
// [[SHORT_EXAMPLE_TITLE]]
// Your code here…
❌ Common Mistakes
- God Classes (large classes doing everything)
- Mixing business logic with infrastructure
- Sending emails inside business classes
- Logging inside domain models
- Database access mixed with business logic
- Utility classes that keep growing forever
✅ Best Practices
- Keep classes focused on one business responsibility.
- Separate business, data access, logging, and notification logic.
- Use Dependency Injection for external services.
- Keep methods small and cohesive.
- Prefer composition over large monolithic classes.
- Refactor when a class gains multiple reasons to change.
💬 Senior-Level Discussion Points
- SRP is about reasons to change, not simply the number of methods.
- A class may have many methods if they all support the same responsibility.
- SRP increases cohesion and reduces coupling.
- SRP works together with Dependency Injection and Clean Architecture.
- Violating SRP often leads to poor unit testing and difficult maintenance.
- Over-applying SRP can create unnecessary classes; balance is important.
💡 Interview Definition
The Single Responsibility Principle states that a class should have only one responsibility, meaning it should have only one reason to change. Each class should focus on a single business concern, improving maintainability, readability, reusability, and testability. For example, a UserService should manage user operations only, while email notifications and logging should be handled by separate services.
No comments:
Post a Comment