The Chain of Responsibility design pattern solves problems like:
How can coupling the sender of a request to its receiver be avoided?
How can more than one object handle a request?
See Applicability section for all problems Chain of Responsibility can solve. See Solution section for how Chain of Responsibility solves the problems.

• An inflexible way is to implement (hard-wire) a request (receiver1.operation1()) directly within the class (Sender) that sends the request.
• This commits (couples) the sender of a request to a particular receiver at compile-time and makes it impossible to specify more than one receiver.
• That's the kind of approach to avoid if we want to specify multiple objects that can handle a request.
• For example, providing context-sensitive help in a GUI/Web application.
  In a context-sensitive help system, a user can click anywhere to get help information. That is, multiple objects exist that can handle a help request by providing a specific help information. Which object provides the help isn't known at compile-time and should be determined at run-time (depending on run-time conditions).
  "The problem here is that the object that ultimately provides the help isn't known explicitly to the object [sender] (e.g., the button) that initiates the help request." [GoF, p223]