Chain of Responsibility模式详解--设计模式（21）

Chain of Responsibility模式来源：

        熟悉VC/MFC的都知道，VC是“基于消息，事件驱动”，消息在VC开发中起着举足轻重的作用。在MFC中，消息是通过一个向上递交的方式进行处理，例如个WM_COMMAND消息的处理流程:

  注明：有关MFC消息处理更加详细信息，请参考候捷先生的《深入浅出MFC》。

        MFC提供了消息的处理的链式处理策略，处理消息的请求将沿着预先定义好的路径依次进行处理。消息的发送者并不知道该消息最后是由那个具体对象处理的，当然它也无须也不想知道，但是结构是该消息被某个对象处理了，或者一直到一个终极的对象进行处理了。Chain of Responsibility模式描述其实就是这样一类问题将可能处理一个请求的对象链接成一个链，并将请求在这个链上传递，直到有对象处理该请求（可能需要提供一个默认处理所有请求的类，例如MFC中的CwinApp类。

       实际上现实中也有很多这样的例子，比如员工请假审核，每个公司都有自己的请假制度。我们不妨假设：请假半天只要和部门主管说一声就行了，请假在1天要通过人事部门，而请假超过2天就不那么好申请了，这时可能要总经理或者更高级别的人同意才行了。如果不考虑设计模式直接写代码，要完成这个逻辑就可能用到if—else或者多个if了，看到这个代码，就知道了存在许多的问题，比如现在要扩展怎么办呢？比如又有了董事长，可以处理一个月的请假，这时就要修改这么Manager类中的deal_holiday方法了，显然不符合单一职责原则（SRP）和开放-封闭原则（OCP），这种类自然也是不合理的类了