Java设计模式之责任链模式 原
Java设计模式之责任链模式 原
引入责任链模式
责任链模式
顾名思义，责任链模式（Chain of Responsibility Pattern）为请求创建了一个接收者对象的链。这种模式给予请求的类型，对请求的发送者和接收者进行解耦。这种类型的设计模式属于行为型模式。在这种模式中，通常每个接收者都包含对另一个接收者的引用。如果一个对象不能处理该请求，那么它会把相同的请求传给下一个接收者，依此类推。
介绍
意图：避免请求发送者与接收者耦合在一起，让多个对象都有可能接收请求，将这些对象连接成一条链，并且沿着这条链传递请求，直到有对象处理它为止。
主要解决：职责链上的处理者负责处理请求，客户只需要将请求发送到职责链上即可，无须关心请求的处理细节和请求的传递，所以职责链将请求的发送者和请求的处理者解耦了。
何时使用：在处理消息的时候以过滤很多道。
如何解决：拦截的类都实现统一接口。
关键代码：Handler 里面聚合它自己，在 HanleRequest 里判断是否合适，如果没达到条件则向下传递，向谁传递之前 set 进去。
应用实例： 1、红楼梦中的"击鼓传花"。 2、JS 中的事件冒泡。 3、JAVA WEB 中 Apache Tomcat 对 Encoding 的处理，Struts2 的拦截器，jsp servlet 的 Filter。
优点： 1、降低耦合度。它将请求的发送者和接收者解耦。 2、简化了对象。使得对象不需要知道链的结构。 3、增强给对象指派职责的灵活性。通过改变链内的成员或者调动它们的次序，允许动态地新增或者删除责任。 4、增加新的请求处理类很方便。
缺点： 1、不能保证请求一定被接收。 2、系统性能将受到一定影响，而且在进行代码调试时不太方便，可能会造成循环调用。 3、可能不容易观察运行时的特征，有碍于除错。
使用场景： 1、有多个对象可以处理同一个请求，具体哪个对象处理该请求由运行时刻自动确定。 2、在不明确指定接收者的情况下，向多个对象中的一个提交一个请求。 3、可动态指定一组对象处理请求。
注意事项：在 JAVA WEB 中遇到很多应用。
Support是一个抽象类，他的核心方法support中，如果当前support可以解决，就解决，如果不行，就交给next去解决。
package cn.chinotan.service.designpattern.command.ChainOfResponsibility;
/**
* @program: test
* @description: 当前节点可以解决就解决，否则交给下一个节点
* @author: xingcheng
* @create: 2018-09-16 16:41
**/
public abstract class Support {
/**
* 处理节点名称
*/
private String name;
/**
* 下一个处理节点
*/
private Support next;
public Support(String name) {
this.name = name;
}
public final void support(Problem problem){
if (resolve(problem)){
success(problem);
} else if (next != null){
next.support(problem);
} else {
fail(problem);
}
}
/**
* 进行解决
* @param problem 待解决的问题
* @return
*/
protected abstract Boolean resolve(Problem problem);
/**
* 解决失败
* @param problem 待解决的问题
*/
protected void fail(Problem problem){
System.out.println(problem + "无法解决");
}
/**
* 成功解决
* @param problem 待解决的问题
*/
protected void success(Problem problem){
System.out.println(problem + "解决成功} by " + this);
}
@Override
public String toString() {
final StringBuilder sb = new StringBuilder();
sb.append("[name='").append(name).append("]");
return sb.toString();
}
public Support setNext(Support next) {
this.next = next;
return next;
}
}然后我们实现几个具体的support类 NoSupport类是一个永远不解决问题的类
package cn.chinotan.service.designpattern.command.ChainOfResponsibility;
/**
* @program: test
* @description: 永远不解决问题的节点
* @author: xingcheng
* @create: 2018-09-16 17:02
**/
public class NotSupport extends Support{
public NotSupport(String name) {
super(name);
}
@Override
protected Boolean resolve(Problem problem) {
return false;
}
}LimitSupport类，解决指定范围内的问题
package cn.chinotan.service.designpattern.command.ChainOfResponsibility;
/**
* @program: test
* @description: 解决部分范围的问题
* @author: xingcheng
* @create: 2018-09-16 17:15
**/
public class LimitSupport extends Support {
private Integer limit;
public LimitSupport(Integer limit, String name) {
super(name);
this.limit = limit;
}
@Override
protected Boolean resolve(Problem problem) {
if (problem.getCount() < limit){
return true;
} else {
return false;
}
}
}EvenSupport类,解决偶数的问题
package cn.chinotan.service.designpattern.command.ChainOfResponsibility;
/**
* @program: test
* @description: 只解决部分问题的节点
* @author: xingcheng
* @create: 2018-09-16 17:02
**/
public class EvenSupport extends Support {
public EvenSupport(String name) {
super(name);
}
@Override
protected Boolean resolve(Problem problem) {
if ((problem.getCount() & 1) == 0){
return true;
} else {
return false;
}
}
}启动测试类
package cn.chinotan.service.designpattern.command.ChainOfResponsibility;
/**
* @program: test
* @description: 测试启动类
* @author: xingcheng
* @create: 2018-09-16 17:28
**/
public class DemoTest {
public static void main(String[] args) {
NotSupport noSupport = new NotSupport("noSupport");
LimitSupport limitSupport100 = new LimitSupport(100, "limitSupport100");
LimitSupport limitSupport200 = new LimitSupport(200, "limitSupport200");
LimitSupport limitSupport300 = new LimitSupport(300, "limitSupport300");
EvenSupport evenSupport = new EvenSupport("evenSupport");
SpecialSupport specialSupport = new SpecialSupport(363, "specialSupport");
noSupport.setNext(limitSupport100).setNext(limitSupport200).setNext(limitSupport300).setNext(evenSupport).setNext(specialSupport);
for (int i = 0; i < 500; i+= 33){
noSupport.support(new Problem(i));
}
}
}Main类中定义了一个责任链，将几个support对象连接在一起，组成了一条责任链，然后去处理问题 运行结果如下：
责任链模式的分析
首先，责任链模式中，存在着这么几个角色：
- Handler处理者 handler金额use定义了处理请求的接口，handler知道，下一个处理者是谁，如果自己无法处理请求，就转给下一个处理者。 在实例中对应的是，support类和support方法
- concreteHandler(具体的处理者) 具体的处理者是处理请求的具体角色。 在此实例中，由NotSupport角色和其他几个类扮演
- Client 请求者角色，就是向第一个具体的handler发送请求的角色，并连接好责任链，实例中对应的是main类的main方法。
责任链的作用
- 弱化了发出请求的人和处理请求的人之间的关系 发出请求的人只需要向第一个具体的处理者发送请求，然后就可以不用管了，处理者会在责任链上自己寻找处理的方法。 这样就解耦了处理者和请求者之间的关系。 如果我们不采取责任链模式，那么请求者就必须要很清楚哪个处理者能处理它的请求，就必须对所有的处理者都有所了解，类似于上帝视角，然而在实际中，要求请求这了解这么多是不实际的
- 可以动态的改变责任链 责任链还有的好处就是可以动态的改变责任，删除或者添加或者改变顺序。
- 让各个处理者专注于实现自己的职责 责任链模式同时还做到了处理者之间的解耦，处理者自己专注于自己的处理逻辑就好，不管其他处理者干什么。
- 推卸责任也可能导致处理延迟 我们可以责任链模式需要在责任链上传播责任，直至找到合适的处理对象。这样提高了程序的灵活性，但同时也出现了处理的延迟，因为有一个寻找的过程。所以需要低延迟的情况下，就不应该使用责任链模式
责任链模式的应用
1、servlet中的Filter，servlet中分别定义了一个 Filter和FilterChain的接口，定义一个Chain，里面包含了Filter列表和servlet，达到在调用真正servlet之前进行各种filter逻辑
2、Dubbo中的Filter，Dubbo在创建Filter的时候是另外一个方法，通过把Filter封装成 Invoker的匿名类，通过链表这样的数据结构来完成责任链，Dubbo的责任链就没有类似FilterChain这样的类把Filter和调用Invoker结合起来，而是通过创建一个链表，调用的时候我们只知道第一个节点，每个节点包含了下一个调用的节点信息。 这里的虽然Invoker封装Filter没有显示的指定next，但是通过java匿名类和final的机制达到同样的效果
3、Mybatis中的Plugin，Mybatis可以配置各种Plugin，无论是官方提供的还是自己定义的，Plugin和Filter类似，就在执行Sql语句的时候做一些操作。Mybatis的责任链则是通过动态代理的方式，使用Plugin代理实际的Executor类。（这里实际还使用了组合模式，因为Plugin可以嵌套代理）
责任链的优点和缺点
优点：实现了请求者与处理者代码分离：发出这个请求的客户端并不知道链上的哪一个对象最终处理这个请求，这使得系统可以在不影响客户端的情况下动态地重新组织和分配责任。提高系统的灵活性和可扩展行。
缺点：每次都是从链头开始：这也正是链表的缺点。你也许会想到一种貌似不错的解决方案，比如使用hash映射，将要处理的请求id与处理类对象关联，但是这样系统损失了可扩展性。
(adsbygoogle = window.adsbygoogle || []).push({});