Overview
The Chain of Responsibility design pattern is a behavioral design pattern that allows an object to pass the request along a chain of handlers. Upon receiving a request, each handler decides either to process the request or to pass it to the next handler in the chain. It's particularly useful for handling a request in various ways or by different types of objects without coupling the sender of the request to the concrete classes of the receivers. This pattern promotes the principle of loose coupling and is often applied in situations where a request might be handled by multiple objects, each one responsible for a part of its processing.
Key Concepts
- Handler Interface: Defines a standard for handlers in the chain, including a method for processing requests and, typically, setting the next handler.
- Concrete Handlers: Implement the handler interface, handle the request if possible, and pass the request to the next handler otherwise.
- Client: Initiates the request to the first handler in the chain.
Common Interview Questions
Basic Level
- What is the Chain of Responsibility pattern and when should it be used?
- Can you write a simple example of the Chain of Responsibility pattern in C#?
Intermediate Level
- How does the Chain of Responsibility pattern promote loose coupling?
Advanced Level
- How would you optimize a Chain of Responsibility to prevent performance issues in a deeply nested chain?
Detailed Answers
1. What is the Chain of Responsibility pattern and when should it be used?
Answer: The Chain of Responsibility pattern is a design pattern that allows an object to pass the request along a chain of potential handlers until one of them handles the request. It should be used when multiple objects can handle a request, but the handler isn't known a priori, instead, it should be determined automatically. It's also suitable when the set of handlers is supposed to be dynamically changed at runtime.
Key Points:
- Promotes decoupling the sender of the request from its receivers.
- Allows setting the chain dynamically at runtime.
- Simplifies code by distributing handling logic among several classes.
Example:
public abstract class Handler
{
protected Handler successor;
public void SetSuccessor(Handler successor)
{
this.successor = successor;
}
public abstract void HandleRequest(int request);
}
public class ConcreteHandler1 : Handler
{
public override void HandleRequest(int request)
{
if (request >= 0 && request < 10)
{
Console.WriteLine($"{this.GetType().Name} handled request {request}");
}
else if (successor != null)
{
successor.HandleRequest(request);
}
}
}
public class ConcreteHandler2 : Handler
{
public override void HandleRequest(int request)
{
if (request >= 10 && request < 20)
{
Console.WriteLine($"{this.GetType().Name} handled request {request}");
}
else if (successor != null)
{
successor.HandleRequest(request);
}
}
}
2. Can you write a simple example of the Chain of Responsibility pattern in C#?
Answer: Below is a simple implementation of the Chain of Responsibility pattern in C#. It demonstrates a chain of two handler classes, each capable of handling a range of integer requests.
Key Points:
- Each handler checks if it can handle the request. If so, it handles it; otherwise, it passes the request to its successor.
- Handlers are linked in a chain where each handler has a reference to the next.
- The client starts the request from the first handler.
Example:
// Continue using the classes from the first example: Handler, ConcreteHandler1, and ConcreteHandler2
class Client
{
static void Main(string[] args)
{
Handler h1 = new ConcreteHandler1();
Handler h2 = new ConcreteHandler2();
h1.SetSuccessor(h2);
// Generate and process requests
int[] requests = { 2, 14, 5, 22, 18, 3, 27, 20 };
foreach (int request in requests)
{
h1.HandleRequest(request);
}
}
}
3. How does the Chain of Responsibility pattern promote loose coupling?
Answer: The Chain of Responsibility pattern promotes loose coupling by decoupling the sender of a request from its receivers. Instead of senders having to know which part of the system can handle a request, they send it to a chain of handlers. Each handler then decides whether to handle the request or pass it on, without any handler needing to know about the internal structure or existence of other handlers.
Key Points:
- Senders and receivers of requests have no explicit knowledge of each other.
- Handlers in the chain can be changed or rearranged dynamically without affecting the client.
- New handlers can be added into the chain without modifying existing code, adhering to the Open/Closed Principle.
Example:
// Assume the previous Handler and ConcreteHandler implementations.
// This flexibility allows you to change the chain's configuration at runtime or to insert new handlers without modifying the client's code, demonstrating loose coupling.
Handler h3 = new CustomHandler();
h2.SetSuccessor(h3);
// Now, h3 is part of the chain, dynamically added without the need to alter the client code.
4. How would you optimize a Chain of Responsibility to prevent performance issues in a deeply nested chain?
Answer: To optimize a Chain of Responsibility and avoid performance issues with a deeply nested chain, consider the following strategies:
- Caching: Implement caching mechanisms to store and quickly retrieve results of frequently made requests, reducing the number of times a request needs to pass through the chain.
- Short-circuiting: Introduce conditions to stop the request from traversing the entire chain once it's clear it cannot be handled further.
- Segmentation: Break down a long chain into smaller, more manageable segments based on request types or processing criteria, limiting the number of handlers a request must pass through.
- Prioritization: Arrange or dynamically reorder handlers based on their likelihood to handle requests, ensuring more frequently used handlers are earlier in the chain.
Example:
public class CachingHandler : Handler
{
private Dictionary<int, string> cache = new Dictionary<int, string>();
public override void HandleRequest(int request)
{
if (cache.ContainsKey(request))
{
Console.WriteLine($"Cache hit for request {request}: {cache[request]}");
return;
}
Console.WriteLine($"Processing request {request}...");
// Simulate processing and caching the result
cache[request] = $"Processed {request}";
if (successor != null)
{
successor.HandleRequest(request);
}
}
}
In this example, a caching layer is added to the processing chain, demonstrating how performance optimizations could be implemented within a Chain of Responsibility pattern.
