Chain of Responsibility pattern in LLD - Cheat Sheet & Quick Revision

Recall & Review

beginner

What is the main purpose of the Chain of Responsibility pattern?

It allows multiple objects to handle a request without knowing which one will handle it. The request passes along a chain until an object handles it.

intermediate

How does the Chain of Responsibility pattern help in system design?

It decouples the sender of a request from its receivers by giving multiple objects a chance to handle the request, improving flexibility and scalability.

beginner

In the Chain of Responsibility pattern, what role does each handler play?

Each handler decides either to process the request or to pass it to the next handler in the chain.

beginner

What is a real-life example of the Chain of Responsibility pattern?

Customer support: A request goes from a junior agent to a senior agent, then to a manager until someone can solve the problem.

intermediate

What is a key benefit of using the Chain of Responsibility pattern in software systems?

It allows adding or changing handlers dynamically without changing the sender or other handlers, making the system easier to maintain and extend.

What happens if no handler in the Chain of Responsibility can process the request?

A The request is ignored or dropped.

B The request is processed by the first handler anyway.

C The system throws an error immediately.

D The request is sent back to the sender.

If no handler can process the request, it usually gets ignored or dropped as it passes through the chain.

Which of the following best describes the Chain of Responsibility pattern?

A A chain of objects where each can handle or pass a request.

B A single object handles all requests directly.

C Objects communicate by broadcasting messages to all handlers.

D Handlers process requests in parallel.

The pattern involves a chain of objects where each decides to handle or pass the request.

How does the Chain of Responsibility pattern improve system flexibility?

A By requiring all handlers to process every request.

B By hardcoding all handlers in the sender.

C By processing all requests in a fixed order without skipping.

D By allowing handlers to be added or removed without changing the sender.

Handlers can be added or removed dynamically, so the sender does not need to change.

In the Chain of Responsibility, what is the typical structure of handlers?

A Handlers are stored in a global list accessed by all.

B Handlers communicate through a central dispatcher.

C Each handler has a reference to the next handler in the chain.

D Handlers are independent and do not know about each other.

Each handler holds a reference to the next handler to pass the request along.

Which scenario is NOT a good fit for the Chain of Responsibility pattern?

A When multiple objects can handle a request in sequence.

B When all handlers must process the request simultaneously.

C When you want to add or remove handlers easily.

D When the sender should not know which object handles the request.

The pattern is for sequential handling, not simultaneous processing.

Explain the Chain of Responsibility pattern and how it helps in designing flexible systems.

Think about how a support ticket moves through different levels of help.

Describe a real-world example of the Chain of Responsibility pattern and how it works step-by-step.

Imagine passing a question from a junior to a senior person until someone can answer.

Practice

1. What is the main purpose of the Chain of Responsibility pattern in system design?

easy

A. To pass a request along a chain of handlers until one handles it

B. To create multiple copies of an object

C. To ensure only one instance of a class exists

D. To define a family of algorithms and make them interchangeable

Solution

1. Step 1: Understand the pattern's behavior

   The Chain of Responsibility pattern allows a request to be passed along a chain of objects until one can handle it.

2. Step 2: Compare options with the pattern's purpose

   The options describing singleton (one instance), prototype (object copies), and strategy (interchangeable algorithms) refer to other design patterns, not Chain of Responsibility.

3. Final Answer:

   To pass a request along a chain of handlers until one handles it -> Option A

4. Quick Check:

   Chain of Responsibility = pass request along chain [OK]

Hint: Remember: Chain passes request until handled [OK]

Common Mistakes:

• Confusing with Singleton or Strategy patterns
• Thinking it creates object copies
• Assuming it handles all requests at once

2. Which of the following is the correct way to link handlers in a Chain of Responsibility pattern?

easy

A. Handlers are linked using a global static list

B. Handlers are independent and do not reference each other

C. Handlers communicate through a shared database

D. Each handler holds a reference to the next handler in the chain

Solution

1. Step 1: Recall how handlers are connected

   In Chain of Responsibility, each handler has a reference to the next handler to pass the request along.

2. Step 2: Evaluate other options

   Global static lists, shared databases, and independent handlers describe unrelated or incorrect linking methods that contradict the chain concept.

3. Final Answer:

   Each handler holds a reference to the next handler in the chain -> Option D

4. Quick Check:

   Handler links = next handler reference [OK]

Hint: Handlers link by referencing the next handler [OK]

Common Mistakes:

• Using global lists instead of direct references
• Assuming handlers are independent
• Confusing with event broadcasting

3. Consider this simplified handler chain code snippet:

class Handler:
    def __init__(self, successor=None):
        self.successor = successor
    def handle(self, request):
        if self.can_handle(request):
            return f"Handled {request}"
        elif self.successor:
            return self.successor.handle(request)
        else:
            return "Not handled"
    def can_handle(self, request):
        return False

class ConcreteHandlerA(Handler):
    def can_handle(self, request):
        return request == 'A'

class ConcreteHandlerB(Handler):
    def can_handle(self, request):
        return request == 'B'

chain = ConcreteHandlerA(ConcreteHandlerB())
print(chain.handle('B'))

What is the output of this code?

medium

A. Handled B

B. Handled A

C. Not handled

D. Error

Solution

1. Step 1: Trace the request through the chain

   The request 'B' is first checked by ConcreteHandlerA, which returns False for can_handle('B'). It passes the request to ConcreteHandlerB.

2. Step 2: ConcreteHandlerB handles the request

   ConcreteHandlerB's can_handle('B') returns True, so it returns "Handled B".

3. Final Answer:

   Handled B -> Option A

4. Quick Check:

   Request 'B' handled by second handler [OK]

Hint: Request passes chain until a handler returns true [OK]

Common Mistakes:

• Assuming first handler handles all requests
• Confusing return values
• Missing the chain passing logic

4. Given the following code snippet, identify the bug that breaks the Chain of Responsibility pattern:

class Handler:
    def __init__(self, successor=None):
        self.successor = successor
    def handle(self, request):
        if self.can_handle(request):
            return f"Handled {request}"
        else:
            return "Not handled"
    def can_handle(self, request):
        return False

class ConcreteHandler(Handler):
    def can_handle(self, request):
        return request == 'X'

chain = ConcreteHandler()
print(chain.handle('Y'))

What is the main issue here?

medium

A. The successor is not initialized properly

B. The can_handle method always returns True

C. The handler does not pass the request to the successor

D. The handle method has a syntax error

Solution

1. Step 1: Analyze the handle method logic

   The handle method checks can_handle; if False, it returns "Not handled" immediately without passing to successor.

2. Step 2: Identify missing chain passing

   It should call self.successor.handle(request) if successor exists, but this is missing.

3. Final Answer:

   The handler does not pass the request to the successor -> Option C

4. Quick Check:

   Missing successor call breaks chain [OK]

Hint: Always pass request to successor if not handled [OK]

Common Mistakes:

• Forgetting to call successor.handle()
• Assuming can_handle always returns True
• Ignoring successor initialization

5. You are designing a logging system using the Chain of Responsibility pattern. You want to handle logs of different severity: DEBUG, INFO, WARNING, ERROR. Each handler should process logs at its level and pass higher severity logs down the chain. Which design best fits this requirement?

hard

A. Each handler processes only its level and passes all logs to the next handler

B. Each handler processes logs at its level and passes only higher severity logs to the next handler

C. Each handler processes all logs regardless of severity and stops the chain

D. Each handler processes logs randomly without order

Solution

1. Step 1: Understand the logging severity flow

   Logs should be handled at their level, and higher severity logs should continue down the chain for further handling.

2. Step 2: Evaluate options for correct chain behavior

   Each handler processes logs at its level and passes only higher severity logs to the next handler matches this: handlers process their level and pass higher severity logs onward. Each handler processes only its level and passes all logs to the next handler passes all logs regardless, which is inefficient. Each handler processes all logs regardless of severity and stops the chain stops chain prematurely. Each handler processes logs randomly without order is random and incorrect.

3. Final Answer:

   Each handler processes logs at its level and passes only higher severity logs to the next handler -> Option B

4. Quick Check:

   Process level, pass higher severity [OK]

Hint: Process own level, pass higher severity logs down [OK]

Common Mistakes:

• Passing all logs without filtering
• Stopping chain too early
• Ignoring severity order