Single Responsibility Principle

The Single Responsibility Principle (SRP): A Core Pillar of Clean Code Design

The Single Responsibility Principle (SRP) is one of the five principles of object-oriented design known as SOLID, which promotes better design practices for building maintainable, scalable, and robust software systems. SRP was introduced by Robert C. Martin (often referred to as Uncle Bob) and emphasizes that a class should have only one reason to change, or in simpler terms, it should have one responsibility.

What Is the Single Responsibility Principle?

The idea behind SRP is that every class or module in a software system should be responsible for only one functionality or concern. This means that a class should focus on a single task, which ensures that changes in one part of the application affect only the class designed for that specific function.

A class with multiple responsibilities becomes harder to maintain because any modification to one responsibility could unintentionally affect others. This leads to tight coupling and higher complexity in the codebase, making it difficult to manage as the project grows.

By adhering to SRP, we aim to achieve:

Lower coupling: Responsibilities are divided among multiple classes, ensuring changes in one don’t affect others.
Higher cohesion: Each class or module does one thing and does it well, leading to more understandable and maintainable code.
Ease of testing: Testing becomes easier since each class has fewer responsibilities, and unit tests can focus on specific functionalities.

Example of SRP in Python

Initial Example (SRP Violation)

In this example, we have a class OrderService that handles multiple responsibilities: creating an order, sending an email confirmation, and saving the order to a database.

class OrderService:
    def create_order(self, order):
        # Logic to create an order
        print(f”Order {order[‘id’]} created.”)

    def send_order_confirmation_email(self, order):
        # Logic to send email confirmation
        print(f”Email confirmation sent for order {order[‘id’]}.”)

    def save_order_to_database(self, order):
        # Logic to save the order to the database
        print(f”Order {order[‘id’]} saved to the database.”)

class OrderService:

def create_order(self, order):

# Logic to create an order

print(f“Order {order[‘id’]} created.”)

def send_order_confirmation_email(self, order):

# Logic to send email confirmation

print(f“Email confirmation sent for order {order[‘id’]}.”)

def save_order_to_database(self, order):

# Logic to save the order to the database

print(f“Order {order[‘id’]} saved to the database.”)

Here, the OrderService class is doing too much. It is responsible for creating orders, sending confirmation emails, and saving orders to the database, which violates SRP.

Refactored Example (Applying SRP)

To adhere to SRP, we can split this class into three different classes, each responsible for one task: one for handling orders, one for emails, and one for database interactions.

class OrderService:
    def create_order(self, order):
        # Logic to create an order
        print(f”Order {order[‘id’]} created.”)


class EmailService:
    def send_order_confirmation_email(self, order):
        # Logic to send email confirmation
        print(f”Email confirmation sent for order {order[‘id’]}.”)


class OrderRepository:
    def save_order_to_database(self, order):
        # Logic to save the order to the database
        print(f”Order {order[‘id’]} saved to the database.”)

class OrderService:

def create_order(self, order):

# Logic to create an order

print(f“Order {order[‘id’]} created.”)

class EmailService:

def send_order_confirmation_email(self, order):

# Logic to send email confirmation

print(f“Email confirmation sent for order {order[‘id’]}.”)

class OrderRepository:

def save_order_to_database(self, order):

# Logic to save the order to the database

print(f“Order {order[‘id’]} saved to the database.”)

Now, each class has one responsibility:

OrderService handles the creation of orders.
EmailService sends order confirmation emails.
OrderRepository saves the order to the database.

How the Refactored Code Works Together

We can now create instances of each class and call their respective methods to fulfill the tasks.

order = {‘id’: 123, ‘item’: ‘Laptop’, ‘quantity’: 1}

order_service = OrderService()
email_service = EmailService()
order_repository = OrderRepository()

# Handling the order processing
order_service.create_order(order)
email_service.send_order_confirmation_email(order)
order_repository.save_order_to_database(order)

order = {‘id’: 123, ‘item’: ‘Laptop’, ‘quantity’: 1}

order_service = OrderService()

email_service = EmailService()

order_repository = OrderRepository()

# Handling the order processing

order_service.create_order(order)

email_service.send_order_confirmation_email(order)

order_repository.save_order_to_database(order)

In this refactored version:

The code is modular and easier to maintain.
If we need to change how emails are sent (e.g., integrating with a new email service provider), we only need to modify the EmailService class without affecting the order creation or database logic.
Unit testing is simplified because each class now has a single responsibility.

This structure follows the Single Responsibility Principle and promotes clean, maintainable, and scalable code.

Why SRP Matters in Real Projects

In large software projects, following SRP is essential to manage the complexity of the codebase. When responsibilities are spread across multiple classes, changes become more isolated, reducing the risk of unintended side effects. SRP also plays a critical role in facilitating agile practices by making features and modules easier to modify or replace without extensive rewrites.

Moreover, SRP encourages cleaner and more modular code. This modularity allows developers to reuse individual components or swap them out with minimal effort, ensuring the system remains flexible and adaptable to change.

Conclusion

The Single Responsibility Principle is fundamental to writing clean, maintainable code. By adhering to SRP, you ensure that classes in your system are focused on a single task, leading to lower coupling, higher cohesion, and more maintainable code. In the long run, following SRP makes software systems more scalable, testable, and easier to understand. When designing your next class or module, always ask: Does this class have more than one responsibility? If the answer is yes, it’s time to refactor!