CHAIN OF RESPONSIBILITY 是一种对象行为型模式，《设计模式》中：
CHAIN OF RESPONSIBILITY 的意图
CHAIN OF RESPONSIBILITY 的试用条件
CHAIN OF RESPONSIBILITY 的效果
增强了给对象指派 RESPONSIBILITY 的灵活性，可以动态地添加或者修改链中的对象。
The Chain of Responsibility design pattern decouples the sender of a request from its receiver by giving more than one object a chance to handle the request. The pattern chains the receiving objects together and passes the request along the chain until an object handles it. Each object in the chain either handles the request or passes it to the next object in the chain.
The application frameworks include an architecture known as the responder chain. This chain consists of a series of responder objects (that is, objects inheriting from NSResponder or, in UIKit, UIResponder) along which an event (for example, a mouse click) or action message is passed and (usually) eventually handled. If a given responder object doesn’t handle a particular message, it passes the message to the next responder in the chain. The order of responder objects in the chain is generally determined by the view hierarchy, with the progression from lower-level to higher-level responders in the hierarchy, culminating in the window object that manages the view hierarchy, the delegate of the window object, or the global application object. The paths of events and action messages up the responder chain is different. An application can have as many responder chains as it has windows (or even local hierarchies of views); but only one responder chain can be active at a time—the one associated with the currently active window.
The AppKit framework also implements a similar chain of responders for error handling.
iOS Note: UIKit implements the responder chain differently than AppKit does. If a view is managed by a UIViewController object, the view controller becomes the next responder in the chain (and from there the event or action message passes to the view’s superview). In addition, UIKit does not support a document architecture per se; therefore there are no document objects or window-controller objects in the responder chain. There is also no error-handling responder chain in iOS. The design of the view hierarchy, which is closely related to the responder chain, adapts the Composite pattern (Composite). Action messages—messages originating from control objects—are based on the target-action mechanism, which is an instance of the Command pattern (Command).
Uses and Limitations When you construct a user interface for a program either by using Interface Builder or programmatically, you get one or more responder chains “for free.” The responder chain goes hand in hand with a view hierarchy, which you get automatically when you make a view object a subview of a window’s content view. If you have a custom view added to a view hierarchy, it becomes part of the responder chain. If you implement the appropriate NSResponder or UIResponder methods, you can receive and handle events and action messages. A custom object that is a delegate of a window object or the global application object (NSApp in AppKit) can also receive and handle those messages.
You can also programmatically inject custom responders into the responder chain and you can programmatically manipulate the order of responders.
Further Reading: The AppKit responder chains for handling events and action messages and for handling errors are described in Cocoa Event Handling Guide and Error Handling Programming Guide. The UIKit responder chain is described in Event Handling Guide for iOS. The view hierarchy is a related design pattern that is summarized in Composite.