参考答案：在以下情况中，应该使用Chain of Responsibility模式。
(1)多个对象可以处理一个请求，而其处理器却是未知的。
(2)想要在不指定确切的请求接收对象的情况下，向几个对象中的一个发送请求。
(3)可以动态地指定能够处理请求的对象集等。
依题意，在图4—9中，需要考虑以下一些职责链模式实现问题。
(1)实现后继者。链有两种方法可以实现后继者链：①定义新的链接(通常在类Approver中定义，但也可由类Director、类Vicepresident、类Presiden和类Congress来定义)；②使用已有的链接。
通常，可使用已有的对象引用来形成后继者链。例如，在一个部分一整体层次结构中，父构件引用可定义一个部件的后继者，窗口组件(Widget)结构可能早已有这样的链接。在Composite模式中更详细地讨论了父构件引用。当已有的链接能够支持所需的链时，完全可以使用它们。这样就不需要明确定义链接，而且可以节省空间。但如果该结构不能反映应用所需的职责链，那么就必须定义额外的链接。
(2)连接后继者。如果没有已有的引用可定义一个链，那么就必须自己引入它们。这种情况下类Approver不仅定义该请求的接口，通常也维护后继链接。这样类Approver就提供了ApproverRequest的缺省实现，ApproverRequest向后继者(如果有的话)转发请求。如果类Director的子类对该请求不感兴趣，它不需要重定义转发操作，因为它的缺省实现进行无条件的转发。
(3)表示请求。可以用不同的方法表示请求。最简单的形式，请求是一个硬编码的(hard-coded)操作调用。这种形式方便而且安全，但只能转发Approver类定义的固定的一组请求。
另一选择是使用一个处理函数，这个函数以一个请求码(如一个整型常数或一个字符串)为参数。这种方法支持请求数目不限。唯一的要求是发送方和接受方在请求如何编码问题上应达成一致。该方法更为灵活，但它需要用条件语句来区分请求代码以分派请求。另外，无法用类型安全的方法来传递请求参数，因此它们必须被手工打包和解包。显然，相对于直接调用一个操作而言它不太安全。
为解决参数传递问题，可以使用独立的请求对象来封装请求参数。Request类可明确地描述请求，而新类型的请求可用它的子类来定义。这些子类可定义不同的请求参数。处理者必须知道请求的类型(即它们正使用哪一个Request子类)以访问这些参数。为标识请求，Request可定义一个访问器(accessor)函数以返回该类的标识符。或者，如果实现语言支持的话，接受者可使用运行时的类型信息。
(4)在Smalltalk中自动转发。你可以使用Smalltalk中的doseNotUnderstand机制转发请求。没有相应方法的消息被doseNotUnderstand的实现捕捉(trap in)，此实现可被重定义，从而可向一个对象的后继者转发该消息。这样就不需要手工实现转发；类仅处理它感兴趣的请求，而依赖doesNotUnderstand转发所有其他的请求。