标签：流程图 baidu 代码 this png 16px sdn tps 情况
视频讲解链接（审核中......）
1.定义
为了避免请求发送者与多个请求处理者耦合在一起，将所有请求的处理者通过前一对象记住其下一个对象的引用而连成一条链；当有请求发生时，可将请求沿着这条链传递，直到有对象处理它为止。在职责链模式中最关键的一点就是客户提交请求后，请求沿着链往下传递直到有一个处理者处理它，在这里客户无需关心它的请求是哪个处理者来处理，反正总有一个处理者会处理它的请求。接收者和发送者都没有对方明确的信息，同时接收者也不知道职责链中的结构。所以职责链可以简化对象的相互连接，他们只需要保存一个指向其后续者的引用，而不需要保存所有候选者的引用。同时，也可以随时随地的增加或者更改一个处理请求的结构，甚至可以更改处理者的顺序，增加了系统的灵活性。处理灵活性是增加了，但是有时候可能会导致一个请求无论如何也得不到处理，它会被放置在链末端，这个既是职责链的优点也是缺点。
2.结构与实现
2.1结构
职责链模式主要包含以下角色：抽象处理者（Handler）角色：定义一个处理请求的接口，包含抽象处理方法和一个后继连接；具体处理者（Concrete Handler）角色：实现抽象处理者的处理方法，判断能否处理本次请求，如果可以处理请求则处理，否则将该请求转给它的后继者；客户类（Client）角色：创建处理链，并向链头的具体处理者对象提交请求，它不关心处理细节和请求的传递过程。责任链的UML图如下所示：
2.2实现
假如规定学生请假小于或等于 2 天，班主任可以批准；小于或等于 7 天，系主任可以批准；小于或等于 10 天，院长可以批准；其他情况不予批准；这个实例适合使用职责链模式实现。流程图如下：
定义一个领导类（Leader），它是抽象处理者，包含了一个指向下一位领导的指针 next 和一个处理假条的抽象处理方法 handleRequest(int LeaveDays)；然后，定义班主任类（ClassAdviser）、系主任类（DepartmentHead）和院长类（Dean），它们是抽象处理者的子类，是具体处理者，必须根据自己的权力去实现父类的 handleRequest(int LeaveDays) 方法，如果无权处理就将假条交给下一位具体处理者，直到最后；客户类负责创建处理链，并将假条交给链头的具体处理者（班主任)。类图如下：
abstract class Leader { private Leader next; public void setNext(Leader next) { this.next=next; } public Leader getNext() { return next; } public abstract void handleRequest(int LeaveDays); } class ClassAdviser extends Leader { public void handleRequest(int LeaveDays) { if(LeaveDays<=2) { System.out.println("班主任批准您请假" + LeaveDays + "天。"); } else { if(getNext() != null) { getNext().handleRequest(LeaveDays); } else { System.out.println("请假天数太多，没有人批准该假条！"); } } } } class DepartmentHead extends Leader { public void handleRequest(int LeaveDays) { if(LeaveDays<=7) { System.out.println("系主任批准您请假" + LeaveDays + "天。"); } else { if(getNext() != null) { getNext().handleRequest(LeaveDays); } else { System.out.println("请假天数太多，没有人批准该假条！"); } } } } class Dean extends Leader { public void handleRequest(int LeaveDays) { if(LeaveDays<=10) { System.out.println("院长批准您请假" + LeaveDays + "天。"); } else { if(getNext() != null) { getNext().handleRequest(LeaveDays); } else { System.out.println("请假天数太多，没有人批准该假条！"); } } } }
3.优缺点及扩展
3.1优点
降低耦合度。它将请求的发送者和接受者解耦；简化了对象。使得对象不需要知道链的结构；增强给对象指派职责的灵活性。通过改变链内的成员或者调动它们的次序，允许动态地新增或者删除责任；增加新的请求处理类很方便。
3.2缺点
不能保证请求一定被接收；系统性能将受到一定影响，而且在进行代码调试时不太方便；可能会造成循环调用；可能不容易观察运行时的特征，有碍于除错。
3.3扩展
职责链模式存在以下两种情况：一是纯的职责链模式：一个请求必须被某一个处理者对象所接收，且一个具体处理者对某个请求的处理只能采用以下两种行为之一：自己处理（承担责任）；把责任推给下家处理；二是不纯的职责链模式：允许出现某一个具体处理者对象在承担了请求的一部分责任后又将剩余的责任传给下家的情况，且一个请求可以最终不被任何接收端对象所接收。
参考链接：https://wenku.baidu.com/view/04cc624d6bd97f192379e919.html
https://max.book118.com/html/2017/0711/121752783.shtm
http://c.biancheng.net/view/1383.html
https://www.cnblogs.com/cxxjohnson/p/6403849.html
https://blog.csdn.net/m0_37691414/article/details/80672007
https://blog.csdn.net/qq_38005943/article/details/82147987
https://www.jianshu.com/p/85801c01e05c
标签：流程图 baidu 代码 this png 16px sdn tps 情况
原文地址：https://www.cnblogs.com/kyl626/p/12700412.html
