设计模式 ——— 职责链模式

CHAIN OF RESPONSIBILITY(职责链) ———— 对象行为型模式

意图

使多个对象都有机会处理请求，从而避免请求的转发者和接收者之间的耦合关系。将这些对象连成一条链，并沿着这条链传递该请求，直到有一个对象处理它为止。

适用性

如果有多个对象可以处理同一个请求，但是具体由哪个对象来处理该请求，是运行时刻动态确定的。这种情况可以使用职责链模式，把处理请求的对象实现成为职责对象，然后把它们构成一个职责链，当请求在这个链中传递的时候，具体由哪个职责对象来处理，会在运行时动态判断。
如果你想在不明确指定接收者的情况下，向多个对象中的一个提交一个请求的话，可以使用职责链模式，职责链模式实现了请求者和接收者之间的解耦，请求者不需要知道究竟是哪一个接收者对象来处理了请求。
如果想要动态指定处理一个请求的对象集合，可以使用职责链模式，职责链模式能动态的构建职责链，也就是动态的来决定到底哪些职责对象来参与到处理请求中来，相当于是动态指定了处理一个请求的职责对象集合。

结构

Handler(职责接口)
通常在这里定义处理请求的方法，可以在这里实现后继链。
ConcreteHandler(具体职责类)
在这个类里面，实现对在它职责范围内请求的处理，如果不处理，就继续转发请求给后继者。
Client(职责链的客户端)
向链上的具体处理者对象提交请求，让职责链负责处理。

对职责链模式实现的深入探讨

实现后继者链
① 定义新的链接；② 使用已有的链接
当已有的链接能够支持你所需的链时，完全可以使用它们。这样你不需要明确定义链接，而且可以节省空间。但如果该结构不能反映应用所需的职责链，那么你必须定义额外的链接。
比如，当前职责处理对象引用了一个"职责链_One”作为它的后继者链，而这个"职责链_One”中已经存在了它自己的后继者链，假设这个"职责链_One”完整的链为“A ——> B ——> C”。这样当前的职责处理对象其实并没有明确的指定“A ——> B ——> C”这个链，而是通过组合的模式复用了该链。
隐式接收者
当客户端发出请求的时候，客户端并不知道谁会真正处理他的请求，客户端只知道他提交请求的第一个对象。从第一个处理对象开始，整个职责链里面的对象，要么自己处理请求，要么继续转发给下一个接收者。
也就是对于请求者而言，并不知道最终的接收者是谁，但是一般情况下，总是会有一个对象来处理的，因此称为隐式接收者。
一个职责链处理多种请求
① 在Handler中定义不同的方法表示不同的请求。这种形式方便而且安全，但你只能转发Handler类定义的固定的一组请求。
② 定义一个请求对象类(Request)来封装请求的类型和参数。Handler中依旧指定义一个通用的请求方法，该方法不区分请求的类型，所以的请求都是调用该方法，具体的请求类型通过请求对象(Request)中的请求类型属性来标识。那么在具体的接收者中就可以通过Request中标识的不同请求类型进行不同的逻辑处理，处理逻辑依旧是要么处理该请求，要么将该Request对象传递给下一个接收者。
连接后继者
可以在Handler中定义一个请求的缺省实现，即，将请求传递给后继者(如果有后继者的话)。这样一来如果ConcreteHandler子类对该请求不感兴趣，则不需要重定义请求处理操作，因为它的缺省实现会进行无条件的转发。

优缺点

优点：
① 降低耦合度
在职责链模式里面，请求者并不知道接收者是谁，也不知道具体如何处理，请求者只是负责向职责链发出请求就可以了。接收者和请求者都没有对象的明确的信息，且链中的对象不需要知道链的结构。
结果是，职责链可简化接收者对象的相互连接。它们仅需保持一个指向其后续者的引用，而不需要保持它所有的候选接收者的引用。
② 增强了给对象指派职责的灵活性
当在接收者中分派职责时，职责链给你更多的灵活性。你可以通过在运行时刻对该链进行动态的增加或修改来增加或改变处理一个请求的那些职责。

缺点：
① 不保证被接受
既然一个请求没有明确的接收者，那么就不能保证它一定会被处理 ———— 该请求可能一直到链的末端都得不到处理。一个请求也可能因该链没有正确配置而得不到处理。

功能链

在实际开发中，经常会出现一个把职责链稍稍变形的用法。在标准的职责链中，一个请求在职责链中传递，只要有一个对象处理了这个请求，就会停止。
现在稍稍变一下，改成一个请求在职责链中传递，每个职责对象负责处理请求的某一方面的功能，处理完成后，不是停止，而是继续向下传递请求，当请求通过很多职责对象处理过后，功能也就处理完了，把这样的职责链称为功能链。

设计模式 ——— 职责链模式

设计模式 ——— 职责链模式

意图

适用性

结构

对职责链模式实现的深入探讨

优缺点

功能链

相关模式

参考

推荐阅读更多精彩内容