前言：
为什么之前写过Golang 版的设计模式，还在重新写Java版？
答：因为对于我而言，当然也希望对正在学习的大伙有帮助。Java作为一门纯面向对象的语言，更适合用于学习设计模式。
为什么类图要附上uml
因为很多人学习有做笔记的习惯，如果单纯的只是放一张图片，那么学习者也只能复制一张图片，可复用性较低，附上uml，方便有新理解时，快速出新图。
🔥[设计模式Java实现附plantuml源码]专链
- 创建型
- 确保对象的唯一性～单例模式
- 集中式工厂的实现～简单工厂模式
- 多态工厂的实现——工厂方法模式
- 产品族的创建——抽象工厂模式
- 对象的克隆～原型模式
- 复杂对象的组装与创建——建造者模式
- 结构型
- 提供统一入口——外观模式
- 扩展系统功能——装饰模式
- 树形结构的处理——组合模式
- 对象的间接访问——代理模式
- 不兼容结构的协调——适配器模式
- 处理多维度变化——桥接模式
- 实现对象的复用——享元模式
- 行为型
- 请求的链式处理——职责链模式
文章目录
- 请求的链式处理——职责链模式
- 简单代码实现
- 纯与不纯的职责链模式
- 纯的职责链模式
- 不纯的职责链模式
- 总结
- 主要优点
- 主要缺点
- 适用场景
请求的链式处理——职责链模式
很多情况下，在一个软件系统中可以处理某个请求的对象不止一个。例如SCM系统中的采购单审批，主任、副董事长、董事长和董事会都可以处理采购单，他们可以构成一条处理采购单的链式结构。采购单沿着这条链进行传递，这条链就称为职责链。职责链可以是一条直线、一个环或者一个树形结构，最常见的职责链是直线型，即沿着一条单向的链来传递请求。链上的每一个对象都是请求处理者，职责链模式可以将请求的处理者组织成一条链，并让请求沿着链传递，由链上的处理者对请求进行相应的处理，客户端无须关心请求的处理细节以及请求的传递，只需将请求发送到链上即可，实现请求发送者和请求处理者解耦。
职责链模式定义如下：职责链模式（Chain of Responsibility Pattern）：避免将请求发送者与接收者耦合在一起，让多个对象都有机会接收请求，将这些对象连接成一条链，并且沿着这条链传递请求，直到有对象处理它为止。职责链模式是一种对象行为型模式。
@startumlabstract class Handler {
# successor: Handler
+ handlerRequest()
} Handler *--> Handler: successorclass ConcreteHandlerA extends Handler {
+ handlerRequest()
}
class ConcreteHandlerB extends Handler {
+ handlerRequest()
}class Client{}
Client --> Handler: 在client 组建责任链@enduml由图可以看出，在职责链模式结构图中包含以下两个角色。
（1）Handler（抽象处理者）：它定义了一个处理请求的接口，一般设计为抽象类。由于不同的具体处理者处理请求的方式不同，因此在其中定义了抽象请求处理方法。因为每个处理者的下家还是一个处理者，因此在抽象处理者中定义了一个抽象处理者类型的对象（结构图中的successor），作为其对下家的引用。通过该引用，处理者可以连成一条链。
（2）ConcreteHandler（具体处理者)：它是抽象处理者的子类，可以处理用户请求。在具体处理者类中实现了抽象处理者中定义的抽象请求处理方法，在处理请求之前需要进行判断，看是否有相应的处理权限，如果可以处理请求就处理它，否则将请求转发给后继者。在具体处理者中可以访问链中下一个对象，以便请求的转发。
在职责链模式里，很多对象由每个对象对其下家的引用而连接起来形成一条链。请求在这个链上传递，直到链上的某一个对象决定处理此请求为止。发出这个请求的客户端并不知道链上的哪一个对象最终处理这个请求，这使得系统可以在不影响客户端的情况下动态地重新组织链和分配责任。
简单代码实现
package havior;public class ChainDemo {public static class Request {private final Integer money;private final String purpose;private final String number;public Request(Integer money, String purpose, String number) {this.money = money;this.purpose = purpose;this.number = number;}public Integer getMoney() {return money;}public String toString(String handlerName) {return handlerName+" 审批通过: Request{" +"money=" + money +", purpose='" + purpose + '\'' +", number='" + number + '\'' +'}';}}public abstract static class Handler {protected final Handler successor;protected final String name;public Handler(Handler handler, String name) {this.successor = handler;this.name = name;}public abstract void handlerRequest(Request request);}public static class ConcreteHandlerA extends Handler {public ConcreteHandlerA(Handler handler) {super(handler, ConcreteHandlerA.class.getSimpleName());}@Overridepublic void handlerRequest(Request request) {System.out.println(request.toString(this.name));if(request.getMoney() < 100) {return;}this.successor.handlerRequest(request);}}public static class ConcreteHandlerB extends Handler {public ConcreteHandlerB(Handler handler) {super(handler, ConcreteHandlerB.class.getSimpleName());}@Overridepublic void handlerRequest(Request request) {System.out.println(request.toString(this.name));if(request.getMoney() < 1000) {return;}this.successor.handlerRequest(request);}}public static void main(String[] args) {Handler chain = new ConcreteHandlerA(new ConcreteHandlerB(null));Request request = new Request(10, "买根辣条", "001");chain.handlerRequest(request);Request request1 = new Request(200, "买个游戏手柄", "002");chain.handlerRequest(request1);Request request3 = new Request(20000, "幻想时刻", "003");chain.handlerRequest(request3); // 这里抛出异常，因为责任链没有包括>=1000的审批}
}结果
ConcreteHandlerA 审批通过: Request{money=10, purpose='买根辣条', number='001'}
ConcreteHandlerA 审批通过: Request{money=200, purpose='买个游戏手柄', number='002'}
ConcreteHandlerB 审批通过: Request{money=200, purpose='买个游戏手柄', number='002'}
ConcreteHandlerA 审批通过: Request{money=20000, purpose='幻想时刻', number='003'}
ConcreteHandlerB 审批通过: Request{money=20000, purpose='幻想时刻', number='003'}
Exception in thread "main" java.lang.NullPointerException: Cannot invoke "havior.ChainDemo$Handler.handlerRequest(havior.ChainDemo$Request)" because "this.successor" is nullat havior.ChainDemo$ConcreteHandlerB.handlerRequest(ChainDemo.java:71)at havior.ChainDemo$ConcreteHandlerA.handlerRequest(ChainDemo.java:55)at havior.ChainDemo.main(ChainDemo.java:84)
纯与不纯的职责链模式
纯的职责链模式
一个纯的职责链模式要求一个具体处理者对象只能在两个行为中选择一个：要么承担全部责任，要么将责任推给下家。不允许出现某一个具体处理者对象在承担了一部分或全部责任后又将责任向下传递的情况。而且在纯的职责链模式中，要求一个请求必须被某一个处理者对象所接收，不能出现某个请求未被任何一个处理者对象处理的情况。在前面的采购单审批实例中应用的是纯的职责链模式。
不纯的职责链模式
在一个不纯的职责链模式中，允许某个请求被一个具体处理者部分处理后再向下传递，或者一个具体处理者处理完某请求后其后继处理者可以继续处理该请求，而且一个请求可以最终不被任何处理者对象所接收。
总结
职责链模式通过建立一条链来组织请求的处理者。请求将沿着链进行传递，请求发送者无须知道请求在何时、何处以及如何被处理，实现了请求发送者与处理者的解耦。在软件开发中，如果遇到有多个对象可以处理同一请求时可以应用职责链模式。例如，在Web应用开发中创建一个过滤器（Filter）链来对请求数据进行过滤，在工作流系统中实现公文的分级审批等，使用职责链模式可以较好地解决此类问题。
主要优点
职责链模式的主要优点如下：
（1）职责链模式使得一个对象无须知道是其他哪一个对象处理其请求。对象仅需知道该请求会被处理即可，接收者和发送者都没有对方的明确信息，且链中的对象不需要知道链的结构。由客户端负责链的创建，降低了系统的耦合度。
（2）请求处理对象仅需维持一个指向其后继者的引用，而不需要维持它对所有的候选处理者的引用，可简化对象的相互连接。
（3）在给对象分派职责时，职责链可以提供更多的灵活性，可以通过在运行时对链进行动态的增加或修改来增加或改变处理一个请求的职责。
（4）在系统中增加一个新的具体请求处理者时无须修改原有系统的代码，只需要在客户端重新建链即可，从这一点来看是符合开闭原则的。
主要缺点
职责链模式的主要缺点如下：
（1）由于一个请求没有明确的接收者，那么就不能保证它一定会被处理，该请求可能一直到链的末端都得不到处理。一个请求也可能因职责链没有被正确配置而得不到处理。
（2）对于比较长的职责链，请求的处理可能涉及多个处理对象，系统性能将受到一定影响，而且在进行代码调试时不太方便。
（3）如果建链不当，可能会造成循环调用，将导致系统陷入死循环。
适用场景
在以下情况下可以考虑使用职责链模式：
（1）有多个对象可以处理同一个请求，具体哪个对象处理该请求待运行时刻再确定。客户端只需将请求提交到链上，而无须关心请求的处理对象是谁以及它是如何处理的。
（2）在不明确指定接收者的情况下，向多个对象中的一个提交一个请求。
（3）可动态指定一组对象处理请求。客户端可以动态创建职责链来处理请求，还可以改变链中处理者之间的先后次序。
🚀 作者简介：作为某云服务提供商的后端开发人员，我将在这里与大家简要分享一些实用的开发小技巧。在我的职业生涯中积累了丰富的经验，希望能通过这个博客与大家交流、学习和成长。技术栈：Java、Golang、PHP、Python、Vue、React
本文收录于三木的
💐 「设计模式」专栏
此外三木还有以下专栏在同步更新～
🌼 「AI」专栏
🔥「面试」这个专栏的灵感来自于许多粉丝私信，大家向我咨询有关面试的问题和建议。我深感荣幸和责任，希望通过这个专栏，能够为大家提供更多关于面试的知识、技巧和经验。我们将一起探讨面试。期待粉丝们ssp的offer喜讯。
🎈 「Java探索者之路」系列专栏，这个专栏旨在引领Java开发者踏上一段真正探索Java世界的旅程。
我们将深入探讨Java编程的方方面面，从基础知识到高级技巧，从实践案例到最新趋势，帮助你成为一名卓越的Java探索者。如果有想进入Java后端领域工作的同学，这个专栏会对你有所帮助，欢迎关注起来呀
🌊 「Python爬虫」的入门学习系列，大家有兴趣的可以看一看
🌹一起学习，互三互访，顺评论区有访必回，有关必回！！！
