这是我参与2022首次更文挑战的第20天,活动详情查看:2022首次更文挑战
责任链模式
责任链模式的概念
责任链模式(Chain of Responsibility Pattern)也被称为职责链模式,责任链模式一般是为了避免请求发送者与多个请求处理者耦合在一起,于是将所有请求的处理者通过前一对象记住其下一个对象的引用而连成一条链;当有请求发生时,可将请求沿着这条链传递,直到有对象处理它为止。换句话说将链中的每一个节点看成一个对象,每个节点的处理请求都不一样,且内部自动维护一个下一个节点对象。 通常来讲,在类的创建过程中,责任链模式属于行为型模式。
责任链模式的基本应用场景
在日常生活中,责任链模式的使用场景特别广泛,比如项目开发,各部门协调完成、请假流程的审批,一般都是经理同意后再往上一层提交申请等场景的使用
在责任链模式中,客户只需要将请求发送到责任链上,客户不无须关心责任链如何对请求的处理细节和请求的传递过程,请求会自动进行传递。所以责任链将请求的发送者和请求的处理者解耦了。
责任链模式主要适用于以下场景
-
多个对象可以处理一个请求,但具体由哪个对象处理该请求在运行时自动确定。
-
可动态指定一组对象处理请求,或添加新的处理者。
-
需要在不明确指定请求处理者的情况下,向多个处理者中的一个提交请求。
责任链模式的通用写法
一般情况下,责任链模式包含三种角色
-
抽象处理者角色(Handler):定义一个处理请求的接口或者抽象类,该类包含抽象处理方法和一个后继连接并维护一个下一个节点的Handler对象的引用
-
具体处理者角色(Concrete Handler):实现抽象处理者的处理方法,判断能否处理本次请求,如果可以处理请求则处理,否则将该请求转给它的后继者。
-
客户类角色(Client):创建处理链,并向链头的具体处理者对象提交请求,它不关心处理细节和请求的传递过程。
责任链模式的本质是解耦请求与处理,让请求在处理链中能进行传递与被处理;理解责任链模式应当理解其模式,而不是其具体实现。责任链模式的独到之处是将其节点处理者组合成了链式结构,并允许节点自身决定是否进行请求处理或转发,相当于让请求流动起来。
通过请假流程案例来实现责任链模式的基本应用
- 抽象处理者(Leader)
public abstract class Leader {
private Leader next;
public Leader getNext() {
return next;
}
public void setNext(Leader next) {
this.next = next;
}
/**
* 处理请求的方法
* @param LeaveDays
*/
public abstract void handleRequest(int LeaveDays);
}
- 具体处理者1:项目经理
public class ProjectHeadHandler extends Leader {
@Override
public void handleRequest(int LeaveDays) {
if (LeaveDays <= 7) {
System.out.println("项目经理准您请假" + LeaveDays + "天。");
} else {
if (getNext() != null) {
getNext().handleRequest(LeaveDays);
}
}
}
}
- 具体处理者2:部门经理
public class DepartmentHeadHandler extends Leader {
@Override
public void handleRequest(int LeaveDays) {
if (LeaveDays <= 14) {
System.out.println("部门经理批准您请假" + LeaveDays + "天。");
} else {
if (getNext() != null) {
getNext().handleRequest(LeaveDays);
} else {
System.out.println("请假天数太多,没有人批准该假条!");
}
}
}
}
- UML结构图
通过上述代码可以看到, 定义一个抽象处理者(leader),主要包含了一个指向下一位用户的指针next和一个处理请假申请的抽象处理方法handleRequest(int LeaveDays);,然后分别定义ProjectHeadHandler、DepartmentHeadHandler两个类,来继承leader类,并具体实现里面的方法。直到请求到链头的最后处理者。
责任链模式的优缺点
优点
-
降低了对象之间的耦合度。该模式使得一个对象无须知道到底是哪一个对象处理其请求以及链的结构,发送者和接收者也无须拥有对方的明确信息。
-
增强了系统的可扩展性。可以根据需要增加新的请求处理类,满足开闭原则。
-
增强了给对象指派职责的灵活性。当工作流程发生变化,可以动态地改变链内的成员或者调动它们的次序,也可动态地新增或者删除责任。
-
责任链简化了对象之间的连接。每个对象只需保持一个指向其后继者的引用,不需保持其他所有处理者的引用,这避免了使用众多的 if 或者 if···else 语句。
-
责任分担。每个类只需要处理自己该处理的工作,不该处理的传递给下一个对象完成,明确各类的责任范围,符合类的单一职责原则。
缺点
-
不能保证每个请求一定被处理。由于一个请求没有明确的接收者,所以不能保证它一定会被处理,该请求可能一直传到链的末端都得不到处理。
-
对比较长的职责链,请求的处理可能涉及多个处理对象,系统性能将受到一定影响。
-
职责链建立的合理性要靠客户端来保证,增加了客户端的复杂性,可能会由于职责链的错误设置而导致系统出错,如可能会造成循环调用。