Chain of Responsibility Design Pattern

The Chain of Responsibility design pattern is a behavioral design pattern that allows an object to pass a request along a chain of handlers. Each handler in the chain decides either to process the request or to pass it along the chain to the next handler.

What is the Chain of Responsibility Design Pattern?

Chain of Responsibility Pattern or Chain of Responsibility Method is a Behavioral Design Pattern, which allows an object to send a request to other objects without knowing who is going to handle it.

• This pattern is frequently used in the chain of multiple objects, where each object either handles the request or passes it on to the next object in the chain if it is unable to handle that request.
• This pattern encourages loose coupling between sender and receiver, providing freedom in handling the request.

Characteristics of the Chain of Responsibility Design Pattern

• Loose Coupling: The pattern promotes loose coupling between the sender and receiver of a request, as the sender doesn’t need to know which object will handle the request and the receiver doesn’t need to know the structure of the chain. 
• Dynamic Chain: The chain can be modified dynamically at runtime, allowing for flexibility in adding or removing handlers without affecting the client code.
• Single Responsibility Principle: Each handler in the chain has a single responsibility, either handling the request or passing it to the next handler, which helps in maintaining a clean and modular design.
• Sequential Order: Requests are processed sequentially along the chain, ensuring that each request is handled in a predefined order.
• Fallback Mechanism: The chain can include a mechanism to handle requests that are not handled by any handler in the chain, providing a fallback or default behavior.
• Variants: The pattern has variants like a linear chain, where each handler has a single successor, or a tree-like structure, where a handler can have multiple successors, allowing for more complex processing logic.
• Enhanced Flexibility: The pattern allows for enhanced flexibility in handling requests, as the chain can be configured or modified to suit different requirements without changing the client code.

Real-World Analogy of the Chain Of Responsibility Design Pattern

Imagine a customer service department with multiple levels of support staff, each responsible for handling different types of customer inquiries based on their complexity. The chain of responsibility can be illustrated as follows:

• Level 1 Support:
  • This represents the first point of contact for customer inquiries. Level 1 support staff handle basic inquiries and provide general assistance. If they cannot resolve the issue, they escalate it to Level 2 support.
• Level 2 Support:
  • This level consists of more experienced support staff who can handle more complex issues that Level 1 support cannot resolve. If Level 2 support cannot resolve the issue, they escalate it to Level 3 support.
• Level 3 Support:
  • This is the highest level of support, consisting of senior or specialized staff who can handle critical or highly technical issues. If Level 3 support cannot resolve the issue, they may involve other departments or experts within the organization.

Components of the Chain of Responsibility Design Pattern

The Chain of Responsibility Pattern consists of the following key components:

1. Handler Interface or Abstract Class

This is the base class that defines the interface for handling requests and, in many cases, for chaining to the next handler in the sequence.

2. Concrete Handlers

These are the classes that implement how the requests are going to be handled. They can handle the request or pass it to the next handler in the chain if it is unable to handle that request.

3. Client

The request is sent by the client, who then forwards it to the chain’s first handler. Which handler will finally handle the request is unknown to the client.

Chain of Responsibility Design Pattern Example

Imagine a customer support system where customer requests need to be handled based on their priority. There are three levels of support: Level 1, Level 2, and Level 3. Level 1 support handles basic requests, Level 2 support handles more complex requests, and Level 3 support handles critical issues that cannot be resolved by Level 1 or Level 2.

Benefit of Using the Chain of Responsibility in this scenario:

The Chain of Responsibility pattern is beneficial in this situation because it allows us to create a chain of handlers, where each handler can either handle a request or pass it to the next handler in the chain. This way, we can easily add or remove handlers without modifying the client code, providing flexibility and scalability in handling customer requests.

Below is the code of above problem statement using Interpreter Pattern:

Let’s break down into the component wise code:

1. Handler Interface

Defines the interface for handling requests. Includes methods for handling requests (handleRequest()) and setting the next handler in the chain (setNextHandler()).

Java

public interface SupportHandler {
    void handleRequest(Request request);
    void setNextHandler(SupportHandler nextHandler);
}

2. Concrete Handlers

Implement the SupportHandler interface. Each handler is responsible for handling requests based on its assigned priority level. If a handler can handle the request, it processes it; otherwise, it passes the request to the next handler in the chain.

Java

public class Level1SupportHandler implements SupportHandler {
    private SupportHandler nextHandler;

    public void setNextHandler(SupportHandler nextHandler) {
        this.nextHandler = nextHandler;
    }

    public void handleRequest(Request request) {
        if (request.getPriority() == Priority.BASIC) {
            System.out.println("Level 1 Support handled the request.");
        } else if (nextHandler != null) {
            nextHandler.handleRequest(request);
        }
    }
}

public class Level2SupportHandler implements SupportHandler {
    private SupportHandler nextHandler;

    public void setNextHandler(SupportHandler nextHandler) {
        this.nextHandler = nextHandler;
    }

    public void handleRequest(Request request) {
        if (request.getPriority() == Priority.INTERMEDIATE) {
            System.out.println("Level 2 Support handled the request.");
        } else if (nextHandler != null) {
            nextHandler.handleRequest(request);
        }
    }
}

public class Level3SupportHandler implements SupportHandler {
    public void handleRequest(Request request) {
        if (request.getPriority() == Priority.CRITICAL) {
            System.out.println("Level 3 Support handled the request.");
        } else {
            System.out.println("Request cannot be handled.");
        }
    }

    public void setNextHandler(SupportHandler nextHandler) {
        // No next handler for Level 3
    }
}

Complete code for the above example

Below is the complete code for the above example:

Java

// Handler Interface
interface SupportHandler {
    void handleRequest(Request request);
    void setNextHandler(SupportHandler nextHandler);
}

// Concrete Handlers
class Level1SupportHandler implements SupportHandler {
    private SupportHandler nextHandler;

    public void setNextHandler(SupportHandler nextHandler) {
        this.nextHandler = nextHandler;
    }

    public void handleRequest(Request request) {
        if (request.getPriority() == Priority.BASIC) {
            System.out.println("Level 1 Support handled the request.");
        } else if (nextHandler != null) {
            nextHandler.handleRequest(request);
        }
    }
}

class Level2SupportHandler implements SupportHandler {
    private SupportHandler nextHandler;

    public void setNextHandler(SupportHandler nextHandler) {
        this.nextHandler = nextHandler;
    }

    public void handleRequest(Request request) {
        if (request.getPriority() == Priority.INTERMEDIATE) {
            System.out.println("Level 2 Support handled the request.");
        } else if (nextHandler != null) {
            nextHandler.handleRequest(request);
        }
    }
}

class Level3SupportHandler implements SupportHandler {
    public void handleRequest(Request request) {
        if (request.getPriority() == Priority.CRITICAL) {
            System.out.println("Level 3 Support handled the request.");
        } else {
            System.out.println("Request cannot be handled.");
        }
    }

    public void setNextHandler(SupportHandler nextHandler) {
        // No next handler for Level 3
    }
}

// Request Class
class Request {
    private Priority priority;

    public Request(Priority priority) {
        this.priority = priority;
    }

    public Priority getPriority() {
        return priority;
    }
}

// Priority Enum
enum Priority {
    BASIC, INTERMEDIATE, CRITICAL
}

// Main Class
public class Main {
    public static void main(String[] args) {
        SupportHandler level1Handler = new Level1SupportHandler();
        SupportHandler level2Handler = new Level2SupportHandler();
        SupportHandler level3Handler = new Level3SupportHandler();

        level1Handler.setNextHandler(level2Handler);
        level2Handler.setNextHandler(level3Handler);

        Request request1 = new Request(Priority.BASIC);
        Request request2 = new Request(Priority.INTERMEDIATE);
        Request request3 = new Request(Priority.CRITICAL);

        level1Handler.handleRequest(request1);
        level1Handler.handleRequest(request2);
        level1Handler.handleRequest(request3);
    }
}

Output

Level 1 Support handled the request.
Level 2 Support handled the request.
Level 3 Support handled the request.

Advantages of the Chain of Responsibility Design Pattern

• Decoupling of Objects: The pattern makes enables sending a request to a series of possible recipients without having to worry about which object will handle it in the end. This lessens the reliance between items.
• Flexibility and Extensibility: New handlers can be easily added or existing ones can be modified without affecting the client code. This promotes flexibility and extensibility within the system.
• Dynamic Order of Handling: The sequence and order of handling requests can be changed dynamically during runtime, which allows adjustment of the processing logic as per the requirements.
• Simplified Object Interactions: It simplifies the interaction between the sender and receiver objects, as the sender does not need to know about the processing logic.
• Enhanced Maintainability: Each handler performs a specific type of processing, which making maintaining and modifying the individual components easier without impacting the overall system.

Disadvantages of the Chain of Responsibility Design Pattern

• Possible Unhandled Requests: The chain should be implemented correctly otherwise there is a chance that some requests might not get handled at all, which leads to unexpected behavior in the application.
• Performance Overhead: The request will go through several handlers in the chain if it is lengthy and complicated, which could cause performance overhead. The processing logic of each handler has an effect on the system’s overall performance.
• Complexity in Debugging: The fact that the chain has several handlers can make debugging more difficult. Tracking the progression of a request and determining which handler is in charge of handling it can be difficult.
• Runtime Configuration Overhead: It may become more difficult to manage and maintain the chain of responsibility if the chain is dynamically modified at runtime.

Conclusion

In conclusion, the Chain of Responsibility pattern is a powerful tool for creating a flexible and extensible chain of handlers to process requests. It promotes loose coupling, making it a valuable addition to your design pattern toolbox when building applications. However, like any design pattern, it should be used judiciously, considering the specific requirements of your application.