系列文章
【设计模式】七大设计原则
【设计模式】第一章:单例模式
【设计模式】第二章:工厂模式
【设计模式】第三章:建造者模式
【设计模式】第四章:原型模式
【设计模式】第五章:适配器模式
【设计模式】第六章:装饰器模式
【设计模式】第七章:代理模式
【设计模式】第八章:桥接模式
【设计模式】第九章:外观模式 / 门面模式
【设计模式】第十章:组合模式
【设计模式】第十一章:享元模式
【设计模式】第十二章:观察者模式
【设计模式】第十三章:模板方法模式
【设计模式】第十四章:策略模式
【设计模式】第十五章:责任链模式
【设计模式】第十六章:迭代器模式
【设计模式】第十七章:状态模式
【设计模式】第十八章:备忘录模式
【设计模式】第十九章:访问者模式
【设计模式】第二十章:解释器模式
【设计模式】第二十一章:命令模式
【设计模式】第二十二章:中介者模式
文章目录
- 系列文章
- 一、定义
- 二、角色分类
- 三、实现方式
- UML图
- 具体实现
- 四、应用场景
- 五、优缺点
- 优点
- 缺点
一、定义
摘自百度百科: 在责任链模式里,很多对象由每一个对象对其下家的引用而连接起来形成一条链。请求在这个链上传递,直到链上的某一个对象决定处理此请求。发出这个请求的客户端并不知道链上的哪一个对象最终处理这个请求,这使得系统可以在不影响客户端的情况下动态地重新组织和分配责任。
二、角色分类
抽象处理者(Handler)
定义了处理请求的接口或者抽象类,并提供了处理请求的的方法和设置下一个处理者的方法
具体处理者(Concrete Handler)
它是抽象处理者的子类,可以处理用户请求,在具体处理者类中实现了抽象处理者中定义的抽象请求处理方法,在处理请求之前需要进行判断,看是否有相应的处理权限,如果可以处理请求就处理它,否则将请求转发给后继者;在具体处理者中可以访问链中下一个对象,以便请求的转发
客户角色(Client)
具体调用方法的角色
三、实现方式
UML图
具体实现
假如我们想用责任链模式实现一个请假流程,可以这么来实现
抽象处理者(Handler)
@Data
public abstract class Handler {
// 处理者姓名
protected String processorName;
// 下一个处理者
protected Handler nextHandler
public Handler (String processorName) {
this.processorName = processorName;
}
/**
* 处理请假抽象方法
* @param name 请假人姓名
* @param numOfDays 请假天数
*/
public abstract boolean process(String name, int numOfDays);
}
具体处理者(Concrete Handler)
/**
* 组长
*/
@Slf4j
public class TeamLeaderHandler extends Handler {
public TeamLeaderHandler(String processorName) {
this.processorName = processorName;
}
@Override
public boolean process(String name, int numOfDays) {
// 创建随机数,值大于3则为通过,否则为不通过
boolean res = (new Random().nextInt(10)) > 3;
String result = res ? "通过" : "驳回";
log.info("组长<{}>审批<{}>的请假申请,请假天数为:<{}>天,审批结果为:<{}>", processorName, name, numOfDays, result);
if(Boolean.FALSE.equals(res)) {
// 审批驳回
return false;
} else if (numOfDays < 3){
// 请假通过且请假天数小于3天时直接通过
return true;
}
// 若审批通过且请假天数大于等于3天时提交给下一个审批人
return nextHandler.process(name, numOfDays);
}
}
/**
* 部门经理
*/
@Slf4j
public class DepartmentManagerHandler extends Handler {
public DepartmentManagerHandler(String processorName) {
super(name);
}
@Override
public boolean process(String name, int numOfDays) {
// 创建一个随机数 当随机数大于3时为通过,否则为不通过
boolean res = (new Random().nextInt(10)) > 3;
String result = result ? "通过" : "驳回";
log.info("部门经理<{}>审批<{}>的请假申请,请假天数为:<{}>天,审批结果为:<{}>", processorName, name, numOfDays, result);
if(Boolean.FALSE.equals(res)) {
// 审批驳回
return false;
} else if (numOfDays <7) {
// 审批通过且审批天数小于7天时直接通过
return true;
}
// 批准天数大于等于7天时提交给下一个审批人
return nextHandler.process(name, numOfDays);
}
/**
* CEO
*/
@Slf4j
public class CEOHandler extends Handler {
public CEOHandler(String processorName) {
super(name);
}
public boolean process(String name, int numOfDays) {
// 创建一个随机数,大于3则为通过,否则为驳回
boolean res = (new Random().nextInt(10)) > 3;
String result = res ? "通过" : "驳回";
log.info("CEO<{}>审批<{}>的请假申请,请假天数为:<{}>天,审批结果为:<{}>", processorName, name, numOfDays, result);
if(Boolean.FALSE.equals(res)) {
//驳回
return false;
}
return true;
}
}
}
客户角色(Client)
public class Client {
public static void main(String[] args) {
Handler zhangsan = new TeamLeaderHandler("张三");
Handler lisi = new DepartmentManagerHandler("李四");
Handler wangwu = new CEOHandler("王五");
// 创建责任链
zhangsan.setNextHandler(lisi);
lisi.setNextHandler(wangwu);
// 发起请假申请
boolean res1 = zhangsan.process("小A", 2);
System.out.println("最终结果:" + res);
boolean res1 = zhangsan.process("小B", 5);
System.out.println("最终结果:" + res);
boolean res1 = zhangsan.process("小C", 10);
System.out.println("最终结果:" + res);
}
}
运行结果
组长<张三>审批<小A>的请假申请,请假天数为:<2>天,审批结果为:<通过>
最终结果:true
部门经理<李四> 审批 <小B> 的请假申请,请假天数: <5>天 ,审批结果:<不通过>
最终结果:false
组长<张三> 审批 <小C> 的请假申请,请假天数: <10> 天,审批结果:<通过>
部门经理<李四> 审批 <小C> 的请假申请,请假天数: <10> 天,审批结果:<通过>
CEO<王五> 审批 <小C> 的请假申请,请假天数: <10> 天,审批结果:<通过>
最终结果:true
四、应用场景
以下部分内容摘自菜鸟教程
意图: 避免请求发送者与接收者耦合在一起,让多个对象都有可能接收请求,将这些对象连接成一条链,并且沿着这条链传递请求,直到有对象处理它为止。
主要解决: 职责链上的处理者负责处理请求,客户只需要将请求发送到职责链上即可,无须关心请求的处理细节和请求的传递,所以职责链将请求的发送者和请求的处理者解耦了。
何时使用: 在处理消息的时候以过滤很多道。
如何解决: 拦截的类都实现统一接口。
关键代码: Handler 里面聚合它自己,在 HandlerRequest 里判断是否合适,如果没达到条件则向下传递,向谁传递之前 set 进去。
应用实例:
- 红楼梦中的"击鼓传花"。
- JS 中的事件冒泡。
- JAVA WEB 中 Apache Tomcat 对 Encoding 的处理,Struts2 的拦截器,jsp servlet 的 Filter。
使用场景:
- 有多个对象可以处理同一个请求,具体哪个对象处理该请求由运行时刻自动确定。
- 在不明确指定接收者的情况下,向多个对象中的一个提交一个请求。
- 可动态指定一组对象处理请求。
注意事项: 在 JAVA WEB 中遇到很多应用。
五、优缺点
优点
- 降低耦合度。它将请求的发送者和接收者解耦。
- 简化了对象。使得对象不需要知道链的结构。
- 增强给对象指派职责的灵活性。通过改变链内的成员或者调动它们的次序,允许动态地新增或者删除责任。
- 增加新的请求处理类很方便。
缺点
- 不能保证请求一定被接收。
- 系统性能将受到一定影响,而且在进行代码调试时不太方便,可能会造成循环调用。
- 可能不容易观察运行时的特征,有碍于除错。