The Chain of Responsibility (CoR) is a way to handle requests in a program without knowing exactly which object will handle them. Instead of one object doing everything, the request is passed along a chain of objects. Each object (called a handler) can either handle the request or pass it to the next one.
How It Works
Imagine a line of people passing a message. The message moves from one person to the next until someone can respond. The sender does not need to know who will handle it. Each handler only focuses on its own job.
Why Use It
-
Loose Coupling: The sender and the handler do not need to know about each other. This makes the system easier to change.
-
Flexible Chain: You can add, remove, or reorder handlers without changing the main code.
-
Single Responsibility: Each handler has only one job: handle the request or pass it along.
-
Sequential Order: Requests are checked one by one in the chain.
-
Fallback Option: If no handler can process the request, the chain can have a default way to handle it.
Benefits of the Chain of Responsibility Pattern
-
Separates Sender and Receiver: The object sending a request does not need to know which object will handle it.
-
Flexible System: You can easily add or remove handlers without changing the rest of the system.
-
Clear Responsibilities: Each handler has only one job, making the code organized and easy to manage.
-
Easy to Scale: You can extend the system by adding new handlers without affecting existing ones.
Common Use Cases
-
Event Handling in GUIs: Events like clicks or key presses move through a chain of components until the right one responds.
-
Logging Systems: Messages move through info, debug, and error loggers until a logger can handle them.
-
Approval Processes: Requests like leave or expense approvals move up a chain of managers until someone with the right authority approves it.
-
Authentication: Different authentication methods (password, OTP, OAuth) can be handled in a chain until one succeeds.
How to Implement the Chain of Responsibility Pattern
-
Define the Handler
Create a base class or interface with methods to process a request and set the next handler in the chain. -
Create Concrete Handlers
Make classes that implement the handler. Each handler deals with requests it can handle and passes the rest to the next handler. -
Set Up the Chain
Create the handler objects and link them by setting the next handler for each one. -
Send Requests
The client sends a request to the first handler. Each handler decides whether to process it or pass it on.
Example 1: ATM Cash Dispenser
Imagine you want to withdraw ₹3,800 from an ATM. The ATM uses a chain of handlers for different note types:
-
The ₹2,000 handler checks if it can give part of the amount. It gives ₹2,000 and passes the remaining ₹1,800 forward.
-
The ₹500 handler takes as much as it can. It gives ₹1,500 and passes the remaining ₹300 forward.
-
The ₹100 handler gives the last ₹300.
Each handler only deals with what it can and passes the rest to the next handler. This is how the Chain of Responsibility pattern works in programming. Each part handles its share of the request, making the system organized and flexible.
Example 2 : Logger System
A logging system is a common use of the Chain of Responsibility pattern:
-
InfoLogger handles general messages.
-
DebugLogger handles debugging messages.
-
ErrorLogger handles serious errors.
When a message is sent, it starts at the top of the chain and moves down until it finds a logger that can handle it. This way, each logger only deals with messages it is responsible for.
Leave Request Flow
In a company, leave requests can follow a chain of responsibility:
-
Leave for 2 days is approved by the Team Lead.
-
Leave for 5 days is approved by the Manager.
-
Leave for longer periods is approved by the Director.
Each leave request moves up the chain until someone with the right authority approves it. This makes the process organized and easy to manage.
Components of the Chain of Responsibility Pattern
-
Handler (Interface or Abstract Class)
This is the base class that defines how requests should be handled. It also knows about the next handler in the chain. -
Concrete Handlers
These are the classes that actually handle the request. If a handler cannot handle the request, it passes it to the next handler in the chain. -
Client
The client sends a request to the first handler in the chain. The client does not need to know which handler will eventually process the request.
UML Diagram
Applications of the Chain of Responsibility Pattern
-
Graphical User Interfaces (GUIs): Events like clicks or key presses move through a chain of components until one handles them.
-
Logging Systems: Different loggers handle messages at different levels (INFO, WARN, ERROR). Each logger passes unhandled messages to the next.
-
Security Systems: Access requests can be checked by a series of handlers, such as role checks and permission checks. Each handler passes the request along if needed.
-
Approval Processes: Leave requests or expense approvals move up a chain of managers until someone with the right authority handles them.
Advantages of the Chain of Responsibility Pattern
-
Requests can be sent without knowing which object will handle them.
-
New handlers can be added or existing ones changed without affecting other parts of the system.
-
The order of handlers can be changed at runtime for flexibility.
-
Simplifies the connection between sender and receiver objects.
Disadvantages of the Chain of Responsibility Pattern
-
If the chain is not set up correctly, some requests may never be handled.
-
Requests may pass through many handlers, which can affect performance.
-
Debugging can be harder because it may be unclear which handler processed a request.
-
Dynamic changes to the chain at runtime can make maintenance more difficult.
Summary
The Chain of Responsibility pattern passes a request along a chain of handlers, where each handler can either process it or pass it to the next. This keeps the system organized and flexible, letting each handler focus on a specific task. It’s useful for things like ATM cash dispensing, logging systems, approval processes, or event handling, where multiple objects might handle a request without the sender needing to know which one will.