Single Responsibility Principle (SRP)

Usage

📝 Guideline

Single Responsibility Principle: Each class should have a single responsibility.

A class should be designed in such a way that it has only one reason to change. It should have a well-defined and focused responsibility, making it easier to understand, maintain, and modify.

🛠️ How to Apply

• Identify clear responsibilities: Define specific tasks and responsibilities for each class. Use meaningful names that reflect their purpose. 🎯
• Separate concerns: Avoid mixing unrelated functionalities within a single class. Delegate tasks to other classes to maintain a focused and modular codebase. 🧩
• Refactor when necessary: If a class grows too large or takes on multiple responsibilities, consider splitting it into smaller, more specialized classes. ♻️

Pros and Cons

👍 Pros

• Improved readability: Classes with single responsibilities are easier to understand, as they focus on a specific task or behavior. 👀
• Enhanced maintainability: When a class has a single responsibility, modifications and updates become simpler and less error-prone. 🛠️
• Enhanced reusability: Well-defined responsibilities allow for greater code reuse by promoting modular design and efficient development. 🔁

👎 Cons

• Increased complexity: Dividing code into multiple classes can introduce additional complexity, requiring careful coordination and communication between them. 🧩
• Potential performance impact: Separating responsibilities may result in additional function calls or inter-class communication, potentially affecting runtime performance. ⏱️
• Higher development effort: Applying the Single Responsibility Principle may require additional upfront effort to analyze and refactor the codebase. ⏰

Examples

❌ Bad

// Bad: A class with multiple responsibilities
 
class UserManager {
  constructor() {
    // ...
  }
 
  getUser(id) {
    // Retrieves user data from the database
  }
 
  updateUser(id, data) {
    // Updates user data in the database
  }
 
  sendEmail(user, message) {
    // Sends an email to the user
  }
}

✅ Good

// Good: Separating responsibilities into distinct classes
 
class UserDatabase {
  constructor() {
    // ...
  }
 
  getUser(id) {
    // Retrieves user data from the database
  }
 
  updateUser(id, data) {
    // Updates user data in the database
  }
}
 
class EmailService {
  constructor() {
    // ...
  }
 
  sendEmail(user, message) {
    // Sends an email to the user
  }
}

References

🧱 SOLID Principles

SOLID is an acronym for five other class-design principles:

• Single Responsibility Principle (SRP)
• Open-Closed Principle (OCP)
• Liskov Substitution Principle (LSP)
• Interface Segregation Principle (ISP)
• Dependency Inversion Principle (DIP)

🔀 Related principles

• Open/Closed Principle: Complements the Single Responsibility Principle by promoting the separation of concerns and facilitating future modifications. 🔒
• Liskov Substitution Principle: Aligns with the Single Responsibility Principle by emphasizing the need for well-defined and consistent behavior. ↔️
• Interface Segregation Principle: Supports the Single Responsibility Principle by advocating for focused and cohesive interfaces. 📚
• Dependency Inversion Principle: Works hand in hand with the Single Responsibility Principle to decouple classes and facilitate maintainability.⚖️
• Don't Repeat Yourself (DRY): Aligns with the Single Responsibility Principle by reducing code duplication within classes and enforcing a focused and concise codebase. 🔄