Unraveling the Design Pattern: Chain of Responsibility

In the realm of software design, the Chain of Responsibility pattern serves as a beacon for creating flexible and decoupled systems. At its core, this pattern revolves around the idea of passing a request through a chain of handlers, each responsible for specific tasks. As we delve into the nuances of this pattern, we discover its ability to promote loose coupling, enabling dynamic and scalable workflows within software architectures.

What?

Chain of responsibility is a behavioural design pattern that allows an object to pass a request along a chain of potential handlers until the request is handled or reaches the end of the chain.

Code

class Handler:
    def __init__(self, next_handler=None):
        self.next_handler = next_handler

    def handle(self, request):
        if self.next_handler:
            self.next_handler.handle(request)


class FrontDesk(Handler):
    def handle(self, request):
        if request == "simple":
            print("FrontDesk: I can handle simple issues.")
        else:
            print("FrontDesk: Passing to Manager.")
            super().handle(request)


class Manager(Handler):
    def handle(self, request):
        if request == "moderate":
            print("Manager: I can handle moderate issues.")
        else:
            print("Manager: Passing to Director.")
            super().handle(request)


class Director(Handler):
    def handle(self, request):
        print("Director: I will handle any escalated issues.")


# Setup chain: FrontDesk → Manager → Director
support_chain = FrontDesk(Manager(Director()))

# Test cases
support_chain.handle("simple")   # Handled by FrontDesk
#FrontDesk: I can handle simple issues.

support_chain.handle("moderate") # Handled by Manager
#FrontDesk: Passing to Manager.
#Manager: I can handle moderate issues.

support_chain.handle("complex")  # Handled by Director
#FrontDesk: Passing to Manager.
#Manager: Passing to Director.
#Director: I will handle any escalated issues.

Output

FrontDesk: I can handle simple issues.
FrontDesk: Passing to Manager.
Manager: I can handle moderate issues.
FrontDesk: Passing to Manager.
Manager: Passing to Director.
Director: I will handle any escalated issues.

• FrontDesk checks the request, if not handled, it passes it to Manager.
  • FrontDesk(Manager())
  • next handler is initiated in def __init__ of parent class
• Manager does the same, passing it to Director if needed.
  • Manager(Director())
  • -> next handler is initiated in def __init__ of parent class
• Director handles any unhandled requests.

Chain of Responsibility vs Method chaining

Both Chain of Responsibility and Method Chaining involve calling multiple methods sequentially, but they serve different purposes.

Chain of Responsibility :

Concept:

• Decouples sender and receiver.
• Passes a request through a chain of handlers until one handles it.
• Each handler decides whether to handle the request or pass it further.
• Promotes loose coupling and flexibility.

Key points

• Each object (handler) decides whether to process or pass it forward.
• Request flows dynamically through the chain.
• Used for problems like event handling, middleware processing, logging, etc..

Method Chaining

Concepts

• Calls multiple methods on the same object sequentially.
• Each method returns self, allowing chaining.
• Improves readability but requires each method to return the instance.

Key Points

• All methods operate on the same object.
• Each method returns self, enabling a chain of operations.
• Used in fluent interfaces like pandas, jQuery, and Builder patterns.

Example

class TextFormatter:
    def __init__(self, text):
        self.text = text

    def uppercase(self):
        self.text = self.text.upper()
        return self  # Returning self allows method chaining

    def remove_spaces(self):
        self.text = self.text.replace(" ", "")
        return self

    def add_prefix(self, prefix):
        self.text = prefix + self.text
        return self

    def show(self):
        print(self.text)

# Using method chaining
text = TextFormatter("hello world")
text.uppercase().remove_spaces().add_prefix(">> ").show() #HELLOWORLD

Differences

When to Use What?

Use Chain of Responsibility when:

• You need to process a request dynamically.
• The handler may or may not process it.
• You want loosely coupled handlers (e.g., middleware in web frameworks).

Use Method Chaining when:

• You need clean, readable method calls on the same object.
• Operations must happen in a fixed order.
• You are working with builders, data processing, or fluent APIs.

Real-World Example

• Chain of Responsibility → Django Middleware, Logging Frameworks
• Method Chaining → pandas DataFrames (df.dropna().sort_values().reset_index())

Use Case of the Chain of Responsibility

The Chain of Responsibility pattern finds practical applications in various real-life scenarios where a series of handlers need to process requests or events in a flexible and decoupled manner. Here are a few examples:

• Event Handling in GUI Frameworks: In graphical user interface (GUI) frameworks, events such as button clicks, key presses, or mouse movements need to be handled by different UI elements. The Chain of Responsibility can be employed to create a chain of event handlers, where each handler is responsible for processing a specific type of event. This allows for the dynamic addition or removal of handlers without modifying the existing codebase.
• Logging Systems: In logging frameworks, different loggers may be responsible for handling logs of varying severity levels. The Chain of Responsibility pattern can be used to create a chain of loggers, each capable of handling logs up to a certain severity threshold. This enables a flexible and configurable logging system where logs are processed and filtered based on their severity.
• Middleware in Web Development: In web development, middleware components often handle various aspects of request processing, such as authentication, logging, or caching. The Chain of Responsibility can be applied to create a middleware pipeline where each component in the chain processes the request or response and passes control to the next middleware in the sequence. This allows for the dynamic composition of middleware and easy extension of the request-handling process.
• Workflow Systems: Workflow systems that involve multiple stages of processing or approval can benefit from the Chain of Responsibility pattern. Each stage in the workflow can be represented by a handler, and the chain defines the sequence in which these stages are executed. This design accommodates changes in the workflow, such as adding new processing steps or modifying the order of existing ones, without necessitating extensive modifications.
• Security Access Control: In security systems, access control policies may involve multiple levels of authorization. The Chain of Responsibility can be applied to model a hierarchy of authorization handlers, where each handler verifies specific aspects of access control. This allows for a flexible and scalable approach to managing permissions and accommodating changes in authorization rules.

By embracing the Chain of Responsibility pattern in these real-life scenarios, developers can create systems that are not only modular and maintainable but also capable of adapting to changing requirements with ease.

Conclusion

In essence, the Chain of Responsibility pattern stands as a design paradigm that champions flexibility and scalability in software architectures. By orchestrating a dynamic chain of handlers, each dedicated to specific responsibilities, the pattern fosters loose coupling and facilitates seamless modifications and extensions. Its adherence to the Single Responsibility Principle ensures modular and maintainable code, while the ability to adjust processing workflows at runtime provides a crucial edge in adapting to evolving requirements. With real-world applications ranging from event handling systems to graphical user interfaces, the Chain of Responsibility pattern remains a cornerstone in crafting resilient, adaptable software solutions that transcend the constraints of static, monolithic structures.

Resources

For further exploration, make sure to check out these helpful resources:

• RefactoringGuru
• GOF