Single Responsibility Principle

💡 What is the Single Responsibility Principle?

At its core, the Single Responsibility Principle (SRP) advocates for a singular focus for each module, class, or function within a software system. In essence, it states that every component should have one and only one reason to change.

Definition: A class, module, or function should have only one reason to change, meaning it should have a single responsibility or purpose.

🔹 In simpler terms:

• A class should do one thing and do it well.
• When each part of a system has a focused role, the code becomes more readable, maintainable, and extensible.

🔍 Why It Matters

When a class does too many things:

• ❌ It becomes harder to understand.
• ❌ Bugs are more likely to appear.
• ❌ Minor changes might introduce unrelated issues.

When SRP is followed:

• ✅ Code becomes easier to test.
• ✅ Reusability increases.
• ✅ Unit testing and maintenance become more straightforward .

Simple Analogy

Imagine you have toys in your room:

• 🏀 A ball is for bouncing.
• 🚗 A toy car is for rolling.
• 🧸 A stuffed animal is for hugging.

Each toy serves one clear purpose.

Likewise, each class or function in your code should serve a single, well-defined purpose or job.

🧮 Example: A Calculator

Suppose you have a calculator that:

• Performs math (add, subtract).
• Display colorful graphics.
• Plays sound effects.

That's a lot for one device! It's better to separate these concerns:

• MathModule: handles math operations.
• GraphicsRenderer: manages UI and visuals.
• SoundManager: deals with sound and audio.

This separation follows SRP.

🧱 Key Concepts

• One Responsibility: A class should do one thing.
• High Cohesion: Related functions grouped logically.
• Low Coupling: Components interact through clear interfaces, minimizing dependencies.

❌ SRP Violation Example (Bad Practice)

Let's look at a class that breaks SRP:

Imagine you're building an application for Employee Management. Here's a class that violates the Single Responsibility Principle:

class Employee {
public:
    string name;
    string position;

    void saveToDatabase() {
        // Code to save the employee details to a database
    }

    void generatePaySlip() {
        // Code to generate the employee's pay slip
    }
};

Problems:

• Manages employee data
• Handles database logic
• Deals with payroll logic

Now the class has multiple reasons to change, violating SRP.

In this case, the Employee class has two reasons to change:

1. Changes in how employee data is saved (Database operations).
2. Changes in how pay slips are generated (Payroll logic).

By combining both responsibilities into the same class, any change related to payroll would require modifications to the Employee class, as would changes related to database operations. This makes the class harder to maintain.

✅ SRP Compliant Example (Good Practice)

Refactor the design into focused classes:

// Class responsible for saving employee data to the database
class EmployeeRepository {
public:
    void saveToDatabase(Employee& employee) {
        // Code to save employee details to a database
    }
};

// Class responsible for generating pay slips
class PaySlipGenerator {
public:
    void generatePaySlip(Employee& employee) {
        // Code to generate pay slip
    }
};

// Employee class now only stores employee information
class Employee {
public:
    string name;
    string position;
};

✅ Now each class has one responsibility:

• Employee: Stores data
• EmployeeRepository: Saves data
• PaySlipGenerator: Generates pay slips

Now, the Employee class is only responsible for storing employee data, while the EmployeeRepository handles saving the data, and the PaySlipGenerator handles generating pay slips. This design adheres to the Single Responsibility Principle.

🍽️ Real-World Analogy

Think of a restaurant:

• The chef cooks
• The cashier handles payments
• The waiter serves food

Imagine one person doing it all — chaos!

SRP is about assigning one job to one person (or class), keeping everything running smoothly.

✅ Benefits of SRP

🧭 When to Apply SRP

Use SRP if:

• A class is doing unrelated tasks
• The class name sounds too broad
• Changes to one part often breaks others

Ask yourself: “Does this class have more than one reason to change?”

If yes – It's time to refactor!

🎯 Conclusion

The Single Responsibility Principle keeps your codebase clean, focused, and easy to work with.

It's a small investment that pays off big in:

• Maintainability
• Readability
• Scalability
• Flexibility
• Debugging

Remember the Golden Rule: One class = One Job