责任链模式——Chain of Responsibility
一、总结《Java设计模式》Chapter12 Chain of Responsibility
? 概述：The intent of the chain responsibility pattern is to avoid coupling the sender of a request to its receiver, by giving more than one object a chance to handle the request.
? 举例：在本工程中，从底层的machine，到line, 到bay，到factory都被看作是MachineComponent(机器组件)；其中machine属于类Machine，后三种属于MachineComposite类，如图所示。当找某个机器组件的负责人时，可能会向上找到它的上层组件的负责人，因为有可能一个工程师负责了一个bay的所有机器。
?? 上面举例会涉及以下优缺点：
1.advantage:
? The advantage of this design is that clients(发出请求者) of machine components don't have to determine how engineers(接收请求者) are assigned.Machine components isolate their clients from knowledge of how responsibilities are assigned.
?
2.disadvantages:
? 在本例中还没有考虑：parent是否为null；责任链是否出现回路。另外两个弊端就是：不是所有的对象都有所有的方法（例如，顶层对象没有parent）；负责机器的工程师change real time没法处理。另外，如果进一步扩充这个例子，引入Tool（工具）和ToolCart（工具车）会再引入一个问题——Tool没有getResponsible()方法，他是由所在ToolCart负责的。
?
? 下面我们就把上面扩充后的例子做成“责任链模式”，类图如上，主要有以下思路：
1、仍然采用责任链的思路，这样可以将“请求发出者”和“请求最终接受（处理）者”解耦合；
2、让所有的“请求直接接受者”(MachineComponent,Tool,ToolCart都是)都实现一个接口，接口中有方法getResponsible()，让接收者自己来决定直接返回内部的responsible属性。显然，Tool类和ToolCart类实现这个方法是不同的，如下：
父亲、丈夫、儿子每个节点有两个选择：要么承担责任，做出回复；要么把请求转发到后序环节。结构分析的已经很清楚了，那我们看怎么来实现这个功能，先看类图：
?我们使用数字来代表女性的不同状态，1是未结婚，2是已经结婚的，而且丈夫建在，3是丈夫去世了的
?从类图上看，三个实现类Father、Husband、Son只要实现构造函数和父类的中抽象方法就可以了，具体怎么处理这些请求，都已经转移到了Hanlder抽象类中，我们来看Hanlder怎么实现：?我们再来看Client类是怎么描述古代这一个礼节的：
?? 据说这个例子最初是《设计模式之禅》上的，特此注明，非我原创。
?
三、如何记忆“责任链模式”
????? 给所有的请求接受者（如“三从四德”中的Father、Husband、Son）一个统一的接口（Handler），接口中有统一的处理请求/消息的接口方法handleMessage()，至于每个请求接受者处理对handleMessage()的实现由两种策略——(1)直接由自己处理；(2)转交给其他Handler子类的handleMessage()处理，即“责任转交/责任链”。??????????????????????????????
?
