画图工具http://draw.iohttp://draw.io是一个免费的画图工具，为用户提供最强大、易用的作图功能，既支持在线画图，也支持离线画图！支持创作系统架构图、流程图、UML图、时序图、思维导图、组织结构图、网络拓扑图、BPMN、UI界面原型设计等。https://www.processon.com/Visio如何制作UML图如何绘制业务流程图：http://www.uml.org.cn/RequirementProject/201207111.aspUML建模之时序图（Sequence Diagram）：http://www.cnblogs.com/ywqu/archive/2009/12/22/1629426.html【UML 建模】UML入门 之 交互图 – 时序图 协作图详解：http://blog.csdn.net/shulianghan/article/details/17927131UML建模之部署图（Deployment Diagram） ： http://www.cnblogs.com/ywqu/archive/2009/12/21/1628545.html看懂UML类图和时序图 :http://www.cleey.com/blog/single/id/873.html流程图流程是一系列的逻辑关系（包含因果关系、时间先后、必要条件、输入输出）产品经理做需求前一定要先把这些逻辑关系理清楚，如果非要用一句话概括的话“流程就是在特定的情境下满足用户特定需要的总结”。2.业务流程图业务流程图又称为泳道图，就是描述那些个体在什么条件下做了什么事情，他们之间有何关联。主要分三个方面：涉及到哪些主体？每个主体都有哪些任务？各个主体之间怎么联系的？一般涉及到多个主体，每个主体之间有联系。系统架构图序列图类图实体关系图E-R图思维导图

观察者模式▐  应用背景在软件系统设计中，我们经常会有这样的需求：如果一个对象的状态发生改变，某些与它相关的对象也要随之做出相应的变化。比如我们会有以下几个场景诉求：如果一个用户关注了一个公众号，那便会收到公众号发来的消息。用户的一个点击事件，会触发界面背景颜色的变更、收到一个后台消息等。由于关联事件的广泛应用，所以观察者模式也是在项目中经常使用的模式之一。▐  基本介绍观察者模式包含观察目标和观察者两类对象，一个目标可以有任意数目的与之相依赖的观察者，一旦观察目标的状态发生改变，所有的观察者都将得到通知。基于上述应用场景的表达，我们可以来看一下该模式的定义。观察者模式（Observer Pattern） 也叫做发布订阅模式（Publish/Subscribe），定义对象间一种一对多的依赖关系，使得每当一个对象改变状态时，则所有依赖于它的对象都会得到通知并被自动更新（Define a one-to-many dependency between objects so that when one object changes state,all its dependents are notified and updated automatically）。观察者模式作为一种对象行为型模式，解决的问题依然是两个关联对象间（观察者和被观察者）的耦合。其通用的类图如下所示：在观察者模式中，会存在几个角色：Subject 被观察者定义被观察者必须实现的职责， 它必须能够动态地增加、 取消观察者。它一般是抽象类或者是实现类， 仅仅完成作为被观察者必须实现的职责：管理观察者并通知观察者。Observer观察者观察者接收到消息后，通过update操作进行处理。ConcreteSubject具体被观察者在基于被观察者自己通用的业务逻辑上，同时可以定义对哪些事件进行通知。ConcreteObserver具体观察者消息接收后，有着不同的处理逻辑。观察模式核心代码：//被观察者public abstract class Subject { //定义一个观察者数组 private Vector<Observer> obsVector = new Vector<Observer>(); //增加一个观察者 public void addObserver(Observer o){ this.obsVector.add(o); } //删除一个观察者 public void delObserver(Observer o){ this.obsVector.remove(o); } //通知所有观察者 public void notifyObservers(){ for(Observer o:this.obsVector){ o.update(); } }} //观察者public interface Observer { //更新方法 public void update();}▐  优缺点分析优点观察者和被观察者之间抽象耦合在扩展能力上，不管是增加观察者还是被观察者都是比较简单的。建立一套触发机制在设计理念上，我们任务每个类的职责都是单一的，即单一职责原则。那么，通过观察者模式我们可以将多个类串联起来，形成一个触发链，构建一个触发机制。缺点在应用观察者模式时，我们需要对开发效率和运行效率特别注意。比如，通用的消息通知形式是以顺序执行的，如果一个观察者出现异常，将会导致整体的执行异常，同时处理时间也严格与每一个观察者节点有关，是累加的关系。因此在复杂场景下，需要考虑采用异步的方式。▐  使用场景事件多级触发场景、跨系统间的消息交换场景等。▐  注意事项在使用观察者模式时，有一个广播链的问题需要特别注意到。广播链问题在设计观察者模式时，会存在这样的一种考虑，一个对象具有双重身份，即又是观察者，也是被观察者。这样，消息就可以在多个节点间传播（和责任链模式有一点点类似，都是建立传播链）。但是该链式结构一旦建立，逻辑就比较复杂，可维护性也是非常差的。根据经验建议，一个观察者模式中，最多出现一个对象既是观察者也是被观察者，即消息最多转发一次，建立三个节点的传播链，这样是比较好控制的。中介模式▐  应用背景DataX是集团内被广泛使用的离线数据同步工具/平台，实现包括 MySQL、Oracle、HDFS、Hive、OceanBase、HBase、OTS、ODPS 等各种异构数据源之间高效的数据同步功能。DataX其实相当于一个中介，从数据源读取数据，同步写入到目标端，数据源不再需要维护到目标端的同步作业，只需要与 DataX 通信即可。DataX体现了中介者模式的思想。▐  基本介绍中介者模式(Mediator Pattern)：用一个中介对象封装一系列的对象交互，中介者使各对象不需要显示地相互作用，从而使其耦合松散， 而且可以独立地改变它们之间的交互（Define an object that encapsulates how a set of objectsinteract.Mediator promotes loose coupling by keeping objects from referring to each other explicitly,and it lets you vary their interaction independently）。显然，中介模式解决的问题依旧是耦合关系。其通用的类图如下：中介模式下存在三个角色，主要包括：Mediator 抽象中介者抽象中介者角色定义统一的接口，用于各同事角色之间的通信。Concrete Mediator 具体中介者通过协调各同事角色实现协作行为，因此它必须依赖于各个同事角色。Colleague 同事角色每个同事角色都会维持者一个对抽象中介者类的引用，可以在需要和其他同事对象通信时，先与中介者通信，通过中介者来间接完成与其他同事类的通信。此外，同事类的行为包括两种，一种是改变自身状态、处理自己行为的自发行为；另一种则是依赖中介者才能完成的依赖行为。中介者模式的核心是引入了中介者类，那么中介者类主要承担了两个责任，其一是中转作用，通过中介者提供的中转作用，各个同事对象就不再需要显式引用其他同事；其二是协调作用，中介者可以更进一步的对同事之间的关系进行封装和分离，而同事类仅需保持一致的和中介者进行交互即可。中介模式核心代码：//抽象中介者类public abstract class Mediator { //定义同事类 protected ConcreteColleague1 c1; protected ConcreteColleague2 c2; //通过getter/setter方法把同事类注入进来 public ConcreteColleague1 getC1() { return c1; } public void setC1(ConcreteColleague1 c1) { this.c1 = c1; } public ConcreteColleague2 getC2() { return c2; } public void setC2(ConcreteColleague2 c2) { this.c2 = c2; } //中介者模式的业务逻辑 public abstract void doSomething1(); public abstract void doSomething2();}//中介者类public class ConcreteMediator extends Mediator { @Override public void doSomething1() { //调用同事类的方法， 只要是public方法都可以调用 super.c1.selfMethod1(); super.c2.selfMethod2(); } public void doSomething2() { super.c1.selfMethod1(); super.c2.selfMethod2(); }}▐  优缺点分析优点中介者模式减少了类间的相互依赖，它用中介者和同事的一对多交互代替了原来同事之间的多对多交互，一对多关系更容易理解、维护和扩展，将原本难以理解的网状结构转换成相对简单的星型结构。缺点中介者模式内中介者会膨胀得很大， 而且包含着大量同事类之间的交互细节，原本N个对象直接的相互依赖关系转换为中介者和同事类的依赖关系，同事类越多，中介者的逻辑就越复杂。▐  使用场景中介者模式适用于多个对象之间紧密耦合的情况，紧密耦合的标准是在类图中出现了蜘蛛网状结构。中介者模式可以将蜘蛛网状结构转变为星型结构，使原本复杂混乱的关系变得清晰且简单。事件触发器最佳实践▐  事件触发器任务今天，我们的任务是来模拟一个事件触发器。有一个产品，它有多个触发事件，它产生的时候会触发一个创建事件，在修改的时候触发修改事件，删除的时候触发删除事件，初始化的时候要触发一个onCreat事件，修改的时候触发onChange事件，双击的时候又触发onDoubleClick事件，例如Button按钮。根据基本任务需求来看，对于多事件动作，我们可以采用工厂方法模式。此外，考虑我们的产品（如GUI设计）经常会使用复制粘贴操作，所以我们也是有一个很明显的设计模式可以使用-原型模式。结合到权限问题，也就是我们的产品并不是谁想产生就产生的，否则触发创建事件的门槛也太容易和简单了。因此，在设计中，我们的产品只能由工厂类创建，而不能被其他对象通过new方式创建，那么在这里，单来源调用（Single Call）方法可以解决。由此我们可以看一下UML图：实现逻辑比较简单，在此可以注意一下isCreateProduct方法和Product的构造函数为何传递进来了一个工厂对象ProductManager。没错，正是解决产品生产的权限问题。在工厂类ProductManager中定义了一个私有变量isPermittedCreate，该变量只有在工厂类的createProduct函数中才能设置为true。在创建产品的时候，产品类Product的构造函数要求传递工厂对象，然后判断是否能够创建产品，即使你想使用类似这样的方法：Productp=new Product(newProductManager(),"abc");也是不能创建出产品的。所以说在产品类中限制了两个生产条件，第一是必须是当前有效的工厂，第二就是拿到了生产资格。所以单来源调用的定义就很明显了，我们将这种一个对象只能由固定的对象初始化的方法叫做单来源调用。//Product产生一个新的产品public Product(ProductManager manager, String name) { //允许建立产品 if (manager.isCreateProduct()) { canChanged = true; this.name = name; }}产生事件的对象有了之后，我们就触发事件了。与此同时，也是要考虑事件的处理对象的。自然而然，观察者模式就可以出场了。那么，UML可以升级为如下所示：观察者模式的设计框架已基本显现，被观察者是Product产品，观察者是EventDispatch事件分发器，具体事件处理我们后面讲，消息的传播对象是ProductEvent事件。接下来，我们看一下具体代码细节。/** * @author la.lda * @date 2020-12-07 */public enum ProductEventType { //新建一个产品 NEW_PRODUCT(1), //删除一个产品 DEL_PRODUCT(2), //修改一个产品 EDIT_PRODUCT(3), //克隆一个产品 CLONE_PRODUCT(4); private int value = 0; ProductEventType(int value) { this.value = value; } public int getValue() { return this.value; }}ProductEventType定义了4个事件类型，分别是新建、修改、删除以及克隆。在产品事件对象中，增加了一个私有方法notifyEventDispatch，该方法的作用就是增加事件观察者，并在有参构造进行初始化时被调用，通知观察者。前面说到，我们采用工厂模式对多事件进行处理，如新建、删除等。而现在产品和事件作为两个独立的对象，如何将两者进行组合关联呢？那工厂类就需要新增一个功能，组合产品和事件，产生有价值的产品事件。ProductManager的代码如下：/** * @author la.lda * @date 2020-12-07 */public class ProductManager { //是否可以创建一个产品 private boolean isPermittedCreate = false; //建立一个产品 public Product createProduct(String name) { //首先修改权限，允许创建 isPermittedCreate = true; Product product = new Product(this, name); //产生一个创建事件 new ProductEvent(product, ProductEventType.NEW_PRODUCT); return product; } //废弃一个产品 public void abandonProduct(Product product) { //销毁一个产品，例如删除数据库记录 new ProductEvent(product, ProductEventType.DEL_PRODUCT); product = null; } //修改一个产品 public void editProduct(Product product, String name) { //修改后产品 new ProductEvent(product, ProductEventType.EDIT_PRODUCT); product.setName(name); } //获得是否可以创建一个产品 public boolean isCreateProduct() { return isPermittedCreate; } //克隆一个产品 public Product clone(Product product) { //产生克隆事件 new ProductEvent(product, ProductEventType.CLONE_PRODUCT); return product.clone(); }}可以看出，每个事件动作下面都增加了事件产生机制，通过组合的形式，产品和事件在扩展性上都有很强的提升。讲述完被观察者以及广播消息后，我们来看一下下游节点-观察者。刚才说到，我们构建了一个事件分发器，为什么要有如此的设计呢？可以想象的到，对于一个事件，自然会有多个处理者，而且一个处理者处理完之后还可能通知其他的处理者。在扩展能力上，我们有新处理者加入之后是否会影响到现有的设计框架呢？因此，本文另外一个设计模式-中介模式就可以上场了。我们将EventDispatch作为中介者，事件的分发器，而事件的处理这都是具体的同事类，它们有独立的处理产品事件的逻辑。当然，我们既然有了一个中心控制，也是可以增加一个功能-权限管理，即EventDispatch能决定观察者能处理什么事件，不能处理什么事件。因此，EventDispatch有三个职责：事件的观察者事件分发器事件处理者管理员那么，我们现在可以完成最后一轮设计结构上的升级了。事件分发器EventDispatch代码：import java.util.ArrayList;import java.util.Observable;import java.util.Observer;/** * @author la.lda * @date 2020-12-07 */public class EventDispatch implements Observer { //单例模式 private final static EventDispatch dispatch = new EventDispatch(); //事件消费者 private ArrayList<EventCustomer> customerList = new ArrayList<EventCustomer>(); //不允许生成新的实例 private EventDispatch() { } //获得单例对象 public static EventDispatch getEventDispatch() { return dispatch; } @Override public void update(Observable o, Object arg) { //事件的源头 Product product = (Product) arg; //事件 ProductEvent event = (ProductEvent) o; //处理者处理，这里是中介者模式的核心，可以是很复杂的业务逻辑 for (EventCustomer e : customerList) { //处理能力是否匹配 for (EventCustomType t : e.getCustomType()) { if (t.getValue() == event.getEventType().getValue()) { e.exec(event); } } } } //注册事件处理者 public void registerCustomer(EventCustomer customer) { customerList.add(customer); }}在EventDispatch里使用ArrayList存储所有的事件处理者，然后在update方法中使用了比较简单for循环完成业务逻辑的判断，其中第一层轮询事件处理者，第二层则轮询事件处理者所能处理的事件类型。只要有事件处理者的处理类型和事件类型相匹配，则调用事件处理方法exec，进入具体事件处理者的特定逻辑中。在这里我们对事件处理者也抽象了一层，抽象类EventCustomer定义了事件处理者通用的能力，也标示出事件处理者必须具备的行为，即定义每个处理者的处理类型。当然，这里也是能够处理多个事件的。import java.util.ArrayList;/** * @author la.lda * @date 2020-12-07 */public abstract class EventCustomer { //容纳每个消费者能够处理的级别 private ArrayList<EventCustomType> customType = new ArrayList<EventCustomType>(); //每个消费者都要声明自己处理哪一类别的事件 public EventCustomer(EventCustomType type) { addCustomType(type); } //每个消费者可以消费多个事件 public void addCustomType(EventCustomType type) { customType.add(type); } //得到自己的处理能力 public ArrayList<EventCustomType> getCustomType() { return customType; } //每个事件都要对事件进行声明式消费 public abstract void exec(ProductEvent event);}接下来，定义三个具体的事件处理者，分别对不同事件类型进行业务逻辑处理。/** * @author la.lda * @date 2020-12-07 */public class Senior extends EventCustomer { public Senior() { super(EventCustomType.EDIT); super.addCustomType(EventCustomType.CLONE); } @Override public void exec(ProductEvent event) { //事件的源头 Product p = event.getSource(); //事件类型 ProductEventType type = event.getEventType(); if (type.getValue() == EventCustomType.CLONE.getValue()) { System.out.println("高级专家处理事件:" + p.getName() + "克隆,事件类型=" + type); } else { System.out.println("高级专家处理事件:" + p.getName() + "修改,事件类型=" + type); } }}/** * @author la.lda * @date 2020-12-07 */public class Middle extends EventCustomer { public Middle() { super(EventCustomType.DEL); } @Override public void exec(ProductEvent event) { //事件的源头 Product p = event.getSource(); //事件类型 ProductEventType type = event.getEventType(); System.out.println("中级专家处理事件:" + p.getName() + "销毁,事件类型=" + type); }}/** * @author la.lda * @date 2020-12-07 */public class Primary extends EventCustomer { public Primary() { super(EventCustomType.NEW); } @Override public void exec(ProductEvent event) { //事件的源头 Product p = event.getSource(); //事件类型 ProductEventType type = event.getEventType(); System.out.println("初级专家处理事件:" + p.getName() + "诞生记,事件类型=" + type); }}最后，我们建立自己的场景，看一下执行情况。/** * @author la.lda * @date 2020-12-07 */public class Client { public static void main(String[] args) { //获得事件分发中心 EventDispatch dispatch = EventDispatch.getEventDispatch(); dispatch.registerCustomer(new Senior()); dispatch.registerCustomer(new Middle()); dispatch.registerCustomer(new Primary()); //建立一个原子弹生产工厂 ProductManager factory = new ProductManager(); //制造一个产品 System.out.println("=====模拟创建产品事件========"); System.out.println("创建一个嫦娥卫星5号"); Product p = factory.createProduct("嫦娥卫星5号"); //修改一个产品 System.out.println("\n=====模拟修改产品事件========"); System.out.println("把嫦娥卫星5号修改为嫦娥卫星6号"); factory.editProduct(p, "嫦娥卫星6号"); //再克隆一个原子弹 System.out.println("\n=====模拟克隆产品事件========"); System.out.println("克隆嫦娥卫星6号"); factory.clone(p); //遗弃一个产品 System.out.println("\n=====模拟销毁产品事件========"); System.out.println("遗弃嫦娥卫星6号"); factory.abandonProduct(p); }}我们的事件处理框架已经生效了，有行为，就产生事件，触发事件处理，三者都相互解耦相互独立，在扩展性上有很大的提升。如果想增加处理者，则建立一个继承EventCustomer的类，然后注册到EventDispatch，就可以进行事件处理了。▐  触发器扩展回顾整个设计流程，感觉某些地方还是可以优化的。如果想扩展产品，也就是观察者想要观察多个产品，如何改进呢？在结合最开始所说，产品是采用单来源调用方式由工厂生产的，那么我们可以进行简单修正来实现产品的扩展性。/** * @author la.lda * @date 12/13/20 */public class ProductA extends Product { public ProductA(ProductManager manager, String name) { super(manager, name, "A"); }}/** * @author la.lda * @date 12/13/20 */public class ProductB extends Product { public ProductB(ProductManager manager, String name) { super(manager, name, "B"); }}从代码结构上可知，抽象Product，以产品类型type来标示子类，工厂通过方法签名生产出不同产品类型的产品。由此，我们彻底完成了观察者、消息以及被观察者的解耦和扩展任务，就可以欢乐的写业务逻辑了。至此，我们以观察者模式和中介模式为主，采用多种经典设计模式，完成了一个可支持多事件分发、处理的事件触发器。设计模式混编总结事件触发框架的设计，结构清晰，扩展性良好，同时也运用了不同的设计模式。原型模式负责对象克隆和拷贝的功能。工厂方法模式负责生产和管理产品对象。观察者模式观察者模式解决了事件如何通知处理者的问题。中介模式中介者模式完美地处理了事件和处理者之间的复杂关系，解决多处理者之间的耦合关系，应对快速的业务变。当然，业务的变化也是无穷的，我们可基于该框架的局部进行不断升级和改进，融入更多的优秀设计模式，提高系统在稳定性、复用性以及扩展性方面的能力。参考书籍《设计模式之禅-设计模式混编》

给大家推荐几个很方便的绘制流程图，架构图的神器。画图画的好，加薪少不了！绘图是一项软技能，图形可以表达比文字更丰富的内容，更清楚的展示逻辑，好的图形可以帮我们更好的表达自己，来看一下几个绘制图形的好工具吧。1. ProcessOn 在线绘制首先放一个注册链接：点击注册 ，推荐使用这个地址注册，可以获得7天会员。可以在7天之内创建多个文件备用，7天之后也会保留。特点类型丰富：流程图，思维导图，思维笔记，原型图，UML类图等,。模板市场：每个账号有9个免费文件额度。有模板市场，非常丰富精美的模板，免费的模板也很多2. 金山文档 在线绘制特点类型丰富：Word, Excel, PPT，思维导图，流程图等，支持协同操作。文件数量不限，总容量1G。(但是单个文件绘制的节点有限制，一般来说还是很够用的)。3. Draw.io 在线绘制 本地客户端绘制特点多种使用方式：在线网站，VSCode插件，本地客户端，也支持NextCloud类型非常丰富：支持各种格式图表支持存储到GitHub仓库。最重要的是：开源！免费！在线使用：VSCode插件方式(安装插件之后，创建.drawio后缀的文件，用VSCode打开即可)：本地安装客户端：

21.观察者模式21.1.课程目标1、 掌握观察者模式和访问者模式的应用场景。2、 掌握观察者模式在具体业务场景中的应用。3、 了解访问者模式的双分派。4、 观察者模式和访问者模式的优、缺点。21.2.内容定位1、 有 Swing开发经验的人群更容易理解观察者模式。 2、 访问者模式被称为最复杂的设计模式。21.3.观察者模式观 察 者 模 式 ( Observer Pattern ) , 又叫发布-订阅( Publish/Subscribe ) 模式、模型-视图 ( Model/View ) 模式、源-监听器(Source/Listener) 模式或从属者( Dependents ) 模式。定义一种一对多的依赖关系，一个主题对象可被多个观察者对象同时监听，使得每当主题对象状态变化时，所有依赖于它的对象都会得到通知并被自动更新。属于行为型模式。原文：Defines a one-to-many dependency relationship between objects so that each time an object' s state changes, its dependent objects are notified and automatically updated.观察者模式的核心是将观察者与被观察者解耦，以类似于消息/广播发送的机制联动两者，使被观察者的变动能通知到感兴趣的观察者们,从而做出相应的响应。21.4.应用场景观察者模式在现实生活应用也非常广泛，比如：起床闹钟设置、APP角标通知、GPer生态圈消息通知、邮件通知、广播通知、桌面程序的事件响应等（如下图）。APP角标通知在软件系统中，当系统一方行为依赖于另一方行为的变动时，可使用观察者模式松耦合联动双方，使得一方的变动可以通知到感兴趣的另一方对象，从而让另一方对象对此做出响应。观察者模式适用于以下几种应用场景：1、当一个抽象模型包含两个方面内容，其中一个方面依赖于另一个方面;2、其他一个或多个对象的变化依赖于另一个对象的变化;3、实现类似广播机制的功能，无需知道具体收听者，只需分发广播,系统中感兴趣的对象会自动接收该广播;4、多层级嵌套使用，形成一种链式触发机制，使得事件具备跨域（跨越两种观察者类型）通知。下面来看下观察者模式的通用UML类 图 ：从 UML类图中,我们可以看到,观察者模式主要包含三种角色:抽象主题(Subject) :指被观察的对象(Observable ) 。该角色是一个抽象类或接口，定义了增加、删除、通知观察者对象的方法；具体主题(ConcreteSubject) :具体被观察者,当其内状态变化时,会通知已注册的观察者; 抽象观察者(Observer) :定义了响应通知的更新方法; 具体观察者(ConcreteObserver) :在得到状态更新时，会自动做出响应。21.5.观察者模式在业务场景中的应用当小伙伴们在GPer生态圈中提问的时候,如果有设置指定老师回答，对应的老师就会收到邮件通 知 ，这就是观察者模式的一种应用场景。我们有些小伙伴可能会想到MQ ,异步队列等,其实JDK本身就提供这样的APIO 我们用代码来还原一下这样一个应用场景，创建GPer类:/** * JDK提供的一种观察者的实现方式，被观察者 */ public class GPer extends Observable { private String name = "GPer生态圈"; private static final GPer gper = new GPer(); private GPer() {} public static GPer getInstance(){ return gper; } public String getName() { return name; } public void publishQuestion(Question question){ System.out.println(question.getUserName() + "在" + this.name + "上提交了一个问题。"); setChanged(); notifyObservers(question); } }创建问题Question类:public class Question { private String userName; private String content; public String getUserName() { return userName; } public void setUserName(String userName) { this.userName = userName; } public String getContent() { return content; } public void setContent(String content) { this.content = content; } }创建老师Teacher类:public class Teacher implements Observer { private String name; public Teacher(String name) { this.name = name; } public void update(Observable o, Object arg) { GPer gper = (GPer)o; Question question = (Question)arg; System.out.println("======================"); System.out.println(name + "老师，你好！\n" + "您收到了一个来自" + gper.getName() + "的提问，希望您解答。问题内容如下：\n" + question.getContent() + "\n" + "提问者：" + question.getUserName()); } }客户端测试代码:public class Test { public static void main(String[] args) { GPer gper = GPer.getInstance(); Teacher tom = new Teacher("Tom"); Teacher jerry = new Teacher("Jerry"); gper.addObserver(tom); gper.addObserver(jerry); //用户行为 Question question = new Question(); question.setUserName("张三"); question.setContent("观察者模式适用于哪些场景？"); gper.publishQuestion(question); } }运行结果:21.6.基于Guava API轻松落地观察者模式给大家推荐一个实现观察者模式非常好用的框架。API使用也非常简单，举个例子，先引入maven依赖包：<dependency> <groupId>com.google.guava</groupId> <artifactId>guava</artifactId> <version>18.0</version> </dependency>创建侦听事件 :public class PojoEvent { @Subscribe public void observer(Pojo pojo){ System.out.println("执行PojoEvent方法，传参为：" + pojo); } }public class VoEvent { @Subscribe public void observer(Vo arg){ System.out.println("执行VoEvent方法，传参为：" + arg); } }客户端测试代码:public class Test { public static void main(String[] args) { EventBus eventBus = new EventBus(); PojoEvent guavaEvent = new PojoEvent(); VoEvent voEvent = new VoEvent(); eventBus.register(guavaEvent); eventBus.register(voEvent); eventBus.post(new Pojo("Tom")); } }运行结果:21.7.使用观察者模式设计鼠标事件响应API下面再来设计一个业务场景，帮助小伙伴更好的理解观察者模式。JDK源码中，观察者模式也应用非常多。例如java.awt.Event就是观察者模式的一种，只不过Java很少被用来写桌面程序。我们自己 用代码来实现一下,以帮助小伙伴们更深刻地了解观察者模式的实现原理。首先，创建EventListener接口 ：/** * 观察者抽象 */ public interface EventListener { }创建Event类:@Data public class Event { //事件源，动作是由谁发出的 private Object source; //事件触发，要通知谁（观察者） private EventListener target; //观察者给的回应 private Method callback; //事件的名称 private String trigger; //事件的触发事件 private long time; public Event(EventListener target, Method callback) { this.target = target; this.callback = callback; } }创建 EventContext 类 ：/** * 被观察者的抽象 */ public class EventContext { protected Map<String,Event> events = new HashMap<String,Event>(); public void addLisenter(String eventType, EventListener target, Method callback){ events.put(eventType,new Event(target,callback)); } public void addLisenter(String eventType, EventListener target){ try { this.addLisenter(eventType, target, target.getClass().getMethod("on" + toUpperFirstCase(eventType), Event.class)); }catch (NoSuchMethodException e){ return; } } private String toUpperFirstCase(String eventType) { char [] chars = eventType.toCharArray(); chars[0] -= 32; return String.valueOf(chars); } private void trigger(Event event){ event.setSource(this); event.setTime(System.currentTimeMillis()); try { if (event.getCallback() != null) { //用反射调用回调函数 event.getCallback().invoke(event.getTarget(), event); } }catch (Exception e){ e.printStackTrace(); } } protected void trigger(String trigger){ if(!this.events.containsKey(trigger)){return;} trigger(this.events.get(trigger).setTrigger(trigger)); } }创建 MouseEventType 接口 :public interface MouseEventType { String ON_CLICK = "click"; String ON_MOVE = "move"; }创建Mouse类 ：/** * 具体的被观察者 */ public class Mouse extends EventContext { public void click(){ System.out.println("调用单击方法"); this.trigger(MouseEventType.ON_CLICK); } public void move(){ System.out.println("调用移动方法"); this.trigger(MouseEventType.ON_MOVE); } }创建回调方法MouseEventLisenter类 ：/** * 观察者 */ public class MouseEventLisenter implements EventListener { public void onClick(Event e){ System.out.println("==========触发鼠标单击事件========\n" + e); } public void onMove(Event e){ System.out.println("==========触发鼠标移动事件========\n" + e); } }客户端测试代码：public class Test { public static void main(String[] args) { MouseEventLisenter lisenter = new MouseEventLisenter(); Mouse mouse = new Mouse(); mouse.addLisenter(MouseEventType.ON_CLICK,lisenter); mouse.addLisenter(MouseEventType.ON_MOVE,lisenter); mouse.click(); mouse.move(); } }运行结果：21.8.观察者模式在源码中的应用Spring 中 的 ContextLoaderListener 实 现 了 ServletContextListener 接 口 ServletContextListener 接口又继承了 EventListener,在 JDK 中 EventListener 有非常广泛的应用。 我们可以看一下源代码，ContextLoaderListener:public class ContextLoaderListener extends ContextLoader implements ServletContextListener { public ContextLoaderListener() { } public ContextLoaderListener(WebApplicationContext context) { super(context); } @Override public void contextInitialized(ServletContextEvent event) { initWebApplicationContext(event.getServletContext()); } @Override public void contextDestroyed(ServletContextEvent event) { closeWebApplicationContext(event.getServletContext()); ContextCleanupListener.cleanupAttributes(event.getServletContext()); } }ServletContextListener 接口源码如下：public interface ServletContextListener extends EventListener { void contextInitialized(ServletContextEvent var1); void contextDestroyed(ServletContextEvent var1); }EventListener接口源码如下：public interface EventListener { }21.7.观察者模式的优缺点优点：1、观察者和被观察者是松耦合（抽象耦合）的 ，符合依赖倒置原则;2、分离了表示层（观察者）和数据逻辑层（被观察者 儿 并且建立了一套触发机制，使得数据的变化可以响应到多个表示层上；3、实现了一对多的通讯机制，支持事件注册机制，支持兴趣分发机制，当被观察者触发事件时，只有感兴趣的观察者可以接收到通知。缺点：1、 如果观察者数量过多，则事件通知会耗时较长;2、 事件通知呈线性关系，如果其中一个观察者处理事件卡壳，会影响后续的观察者接收该事件；3、 如果观察者和被观察者之间存在循环依赖,则可能造成两者之间的循环调用,导致系统崩溃。21.8.思维导图22.访问者模式22.1.定义访问者模式（Visitor Pattern ）是一种将数据结构与数据操作分离的设计模式。是指封装一 些作用于某种数据结构中的各元素的操作，它可以在不改变数据结构的前提下定义作用于这些元素的新的操作。属于行为型模式。原文：Represent an operation to be performed on the elements of an object structure. Visitor lets you define a new operation without changing the classes of the elements on which it operates.访问者模式被称为最复杂的设计模式，并且使用频率不高，设计模式的作者也评价为：大多情况下，你不需要使用访问者模式，但是一旦需要使用它时，那就真的需要使用了。访问者模式的基1=1 本思想是，针对系统中拥有固定类型数的对象结构（元素），在其内提供一个accept()方法用来接受访问者对象的访问。不同的访问者对同一元素的访问内容不同,使得相同的元素集合可以产生不同的数据结果。accept()方法可以接收不同的访问者对象，然后在内部将自己（元 素 ）转发到接收到的访问者对象的visit（）方法内。访问者内部对应类型的visit（）方法就会得到回 调执行，对元素进行操作。也就是通过两次动态分发（第一次是对访问者的分发accept()方法， 第二次是对元素的分发visit()方法），才最终将一个具体的元素传递到一个具体的访问者。如此 —来 ，就解耦了数据结构与操作，且数据操作不会改变元素状态。访问者模式的核心是，解耦数据结构与数据操作，使得对元素的操作具备优秀的扩展性。可以通过扩展不同的数据操作类型（访问者）实现对相同元素集的不同的操作。22.2.应用场景访问者模式在生活场景中也是非常当多的,例如每年年底的KPI考核,KPI考核标准是相对稳定的，但是参与KPI考核的员工可能每年都会发生变化，那么员工就是访问者。我们平时去食堂或者餐厅吃饭,餐厅的菜单和就餐方式是相对稳定的，但是去餐厅就餐的人员是每天都在发生变化的,因此就餐人员就是访问者。当系统中存在类型数目稳定（ 定 ）的一类数据结构时，可以通过访问者模式方便地实现对该类型所有数据结构的不同操作，而又不会数据产生任何副作用（脏数据）。简言之，就是对集合中的不同类型数据（类型数量稳定）进行多种操作，则使用访问者模式。下面总结一下访问者模式的适用场景：1、 数据结构稳定，作用于数据结构的操作经常变化的场景；2、 需要数据结构与数据操作分离的场景； 3、 需要对不同数据类型（元素）进行操作，而不使用分支判断具体类型的场景。首先来看下访问者模式的通用UML类图：从 UML类图中，我们可以看到，访问者模式主要包含五种角色：抽象访问者（Visitor）:接口或抽象类,该类地冠以了对每一个具体元素（Element ）的访 问行为visit（）方法，其参数就是具体的元素（Element）对象。理论上来说,Visitor的方法个 数与元素（Element ）个数是相等的。如果元素（Element ）个数经常变动，会导致Visitor的 方法也要进行变动,此时，该情形并不适用访问者模式；具体访问者（ConcreteVisitor）:实现对具体元素的操作； 抽象元素（Element ）:接口或抽象类，定义了一个接受访问者访问的方法accept() , 表示 所有元素类型都支持被访问者访问；具体元素（Concrete Element ）:具体元素类型，提供接受访问者的具体实现。通常的实现 都 为 ：visitor.visit（this）;结构对象（ObjectStruture ）:该类内部维护了元素集合，并提供方法接受访问者对该集合所有元素进行操作。22.3.利用访问者模式实现KPI考核的场景每到年底，管理层就要开始评定员工一年的工作绩效，员工分为工程师和经理;管理层有CEO和 CTO。那么CTO关注工程师的代码量、经理的新产品数量；CEO关注的是工程师的KPI和经理的KPI以及新产品数量。由于CEO和 CTO对于不同员工的关注点是不一样的，这就需要对不同员工类型进行不同的处理。访问者模式此时可以派上用场了。// 员工基类 public abstract class Employee { public String name; public int kpi; //员工KPI public Employee(String name) { this.name = name; kpi = new Random().nextInt(10); } //接收访问者的访问 public abstract void accept(IVisitor visitor); }Employee类定义了员工基本信息及一个acceptQ方法，acceptQ方法表示接受访问者的访 问 ,由具体的子类来实现。访问者是个接口，传入不同的实现类,可访问不同的数据。下面看看工程师Engineer类的代码：// 工程师类 public class Engineer extends Employee { public Engineer(String name) { super(name); } public void accept(IVisitor visitor) { visitor.visit(this); } //考核指标是每年的代码量 public int getCodeLines(){ return new Random().nextInt(10* 10000); } }经理Manager类的代码：public class Manager extends Employee { public Manager(String name) { super(name); } public void accept(IVisitor visitor) { visitor.visit(this); } //考核的是每年新产品研发数量 public int getProducts(){ return new Random().nextInt(10); } }工程师是考核的是代码数量，经理考核的是产品数量，二者的职责不一样。也正是因为有这样的差异性，才使得访问模式能够在这个场景下发挥作用。Employee. Engineer. Manager这 3个类型就相当于数据结构，这些类型相对稳定，不会发生变化。然后将这些员工添加到一个业务报表类中，公司高层可以通过该报表类的showReport()方 法查看所有员工的业绩，具体代码如下：public class BusinessReport { private List<Employee> employees = new LinkedList<Employee>(); public BusinessReport() { employees.add(new Manager("产品经理A")); employees.add(new Engineer("程序员A")); employees.add(new Engineer("程序员B")); employees.add(new Engineer("程序员C")); employees.add(new Manager("产品经理B")); employees.add(new Engineer("程序员D")); } public void showReport(IVisitor visitor){ for (Employee employee : employees) { employee.accept(visitor); } } }下面看看访问者类型的定义，访问者声明了两个visit()方法，分别对工程师和经理访问，具体代码如下：public interface IVisitor { void visit(Engineer engineer); void visit(Manager manager); }首先定义一个IVisitor接 口 ，该接口有两个visit()方 法 ，参数分别是Engineer. Manager ,也就是说对于Engineer和 Manager的访问会调用两个不同的方法，以此达到差异化处理的目 的。这两个访问者具体的实现类为CEOVisitor类和CTOVisitor类 ，代码如下：public class CEOVistitor implements IVisitor { public void visit(Engineer engineer) { System.out.println("工程师" + engineer.name + "，KIP：" + engineer.kpi); } public void visit(Manager manager) { System.out.println("经理：" + manager.name + ",KPI:" + manager.kpi + "，产品数量：" + manager.getProducts()); } }这就导致了 if-else逻辑的嵌套以及类型的强制转换，难以扩展和维护，当类型较多时，这 个 ReportUtil就会很复杂。而使用访问者模式,通过同一个函数对不同对元素类型进行相应对 处理，使结构更加清晰、灵活性更高。再添加一个CTO的访问者类：public class CTOVistitor implements IVisitor { public void visit(Engineer engineer) { System.out.println("工程师" + engineer.name + "，代码行数：" + engineer.getCodeLines()); } public void visit(Manager manager) { System.out.println("经理：" + manager.name + "，产品数量：" + manager.getProducts()); } }重载的visitO方法会对元素进行不同的操作，而通过注入不同的访问者又可以替换掉访问者 的具体实现，使得对元素的操作变得更灵活，可扩展性更高，同时也消除了类型转换.if-else等“丑陋”的代码。下面是客户端代码：public class Test { public static void main(String[] args) { BusinessReport report = new BusinessReport(); System.out.println("==========CEO看报表==============="); report.showReport(new CEOVistitor()); System.out.println("==========CTO看报表==============="); report.showReport(new CTOVistitor()); } }运行结果如下：在上述案例中, Employee扮演了 Element角 色 ,而 Engineer和 Manager都是 ConcreteElement ; CEOVisitor 和 CTOVisitor 都是具体的 Visitor 对 象 ; 而 BusinessReport就是 Objectstructure。访问者模式最大的优点就是增加访问者非常容易，我们从代码中可以看到，如果要增加一个访问者，只要新实现一个访问者接口的类，从而达到数据对象与数据操作相分离的效果。如果不实用访问者模式，而又不想对不同的元素进行不同的操作，那么必定需要使用if-else和类型 转换，这使得代码难以升级维护。我们要根据具体情况来评估是否适合使用访问者模式，例如，我们的对象结构是否足够稳定，是否需要经常定义新的操作，使用访问者模式是否能优化我们的代码，而不是使我们的代码变得更复杂。22.4.从静态分派到动态分派变量被声明时的类型叫做变量的静态类型(Static Type), 有些人又把静态类型叫做明显类型(Apparent Type); 而变量所引用的对象的真实类型又叫做变量的实际类型(Actual Type)o 比如 ：List list = null; list = new ArrayList();声明了一个变 量list ,它的静态类型(也叫明显类型)是 List ,而它的实际类型是ArrayList。 根据对象的类型而对方法进行的选择，就是分派(Dispatch)。分派又分为两种,即静态分派和动态分派。1、静态分派静态分派(Static Dispatch)就是按照变量的静态类型进行分派，从而确定方法的执行版本, 静态分派在编译时期就可以确定方法的版本。而静态分派最典型的应用就是方法重载'来看下面这段代码。public class Main { public void test(String string){ System.out.println("string" + string); } public void test(Integer integer){ System.out.println("integer" + integer); } public static void main(String[] args) { String string = "1"; Integer integer = 1; Main main = new Main(); main.test(integer); main.test(string); } }在静态分派判断的时候，我们根据多个判断依据(即参数类型和个数)判断出了方法的版本，那么这个就是多分派的概念，因为我们有一个以上的考量标准。所以Java是静态多分派的语言。2、动态分派对于动态分派，与静态相反，它不是在编译期确定的方法版本，而是在运行时才能确定。而动态分派最典型的应用就是多态的特性。举个例子，来看下面的这段代码。public interface Person { void test(); } public class Man implements Person { public void test() { System.out.println("男人"); } } public class WoMan implements Person { public void test() { System.out.println("女人"); } } public class Main { public static void main(String[] args) { Person man = new Man(); Person woman = new WoMan(); man.test(); woman.test(); } }这段程序输出结果为依次打印男人和女人,然而这里的test。方法版本,就无法根据Man 和 Woman的静态类型去判断了，他们的静态类型都是Person接口，根本无从判断。显然，产生的输出结果，就是因为test。方法的版本是在运行时判断的，这就是动态分派。 动态分派判断的方法是在运行时获取到Man和 Woman的实际引用类型，再确定方法的版 本 ，而由于此时判断的依据只是实际引用类型，只有一个判断依据,所以这就是单分派的概念，这时我们的考量标准只有一个，即变量的实际引用类型。相应的，这说明Java是动态单分派的语言。22.5.访问者模式中的伪动态双分派通过前面分析，我们知道Java是静态多分派、动态单分派的语言。Java底层不支持动态的双分派。但是通过使用设计模式，也可以在Java语言里实现伪动态双分派。在访问者模式中使 用的就是伪动态双分派。所谓动态双分派就是在运行时依据两个实际类型去判断一个方法的运行行为，而访问者模式实现的手段是进行了两次动态单分派来达到这个效果。还是回到前面的KPI考核业务场景当中, BusinessReport类中的showReport()方 法 ：public void showReport(IVisitor visitor) { for (Employee employee : employees) { employee.accept(visitor); } }这里就是依据Employee和 IVisitor两个实际类型决定了 showReport()方法的执行结果,从而决定了 accept()方法的动作。 分析accept()方法的调用过程当调用accept()方法时，根 据 Employee的实际类型决定是调用Engineer还 是 Manager的 accept()方法。这时accept()方法的版本已经确定，假如是Engineer , 它的accept()方法是调用下面这行代码。public void accept(IVisitor visitor) { visitor .visit (this); }此时的th is是 Engineer类 型 ,所以对应的是IVisitor接口的visit(Engineer engineer)方法 ，此时需要再根据访问者的实际类型确定Visit()方法的版本，如此一来，就完成了动态双分派的过程。以上的过程就是通过两次动态双分派，第一次对accept方法进行动态分派，第二次对访问 者的visit方法进行动态分派,从而达到了根据两个实际类型确定一个方法的行为的效果。 而原本我们的做法，通常是传入一个接口，直接使用该接口的方法，此为动态单分派,就像策略模式一样。在这里，showReport()方法传入的访问者接口并不是直接调用自己的visit()方 法 ,而是通过Employee的实际类型先动态分派一次，然后在分派后确定的方法版本里再进行自己的动态分派。注意：这里确定accept (IVisitor visitor)方法是静态分派决定的，所以这个并不在此次动态双分派的范畴内，而且 静态分派是在编译期就完成的，所以accept (I Visitor vi si tor)方法的静态分派与访问者模式的动态双分派并没有任 何关系。动态双分派说到底还是动态分派，是在运行时发生的，它与静态分派有着本质上的区别，不可以说一次动态分派加一次静态分派就是动态双分派，而且访问者模式的双分派本身也是另有所指。而 this的类型不是动态确定的，你写在哪个类当中，它的静态类型就是哪个类，这是在编译 期就确定的，不确定的是它的实际类型，请小伙伴也要区分开来。22.6.访问者模式在源码中的应用首先来看JDK的 NIO模块下的Filevisitor,它接口提供了递归遍历文件树的支持。这个接口 上的方法表示了遍历过程中的关键过程，允许你在文件被访问、目录将被访问、目录已被访问、发生错误等等过程上进行控制；换句话说，这个接口在文件被访问前、访问中和访问后，以及产生错误的时候都有相应的钩子程序进行处理。调 用 FileVisitor中的方法,会返回访问结果FileVisitResult对 象 值 ，用于决定当前操作完成后接下来该如何处理。FileVisitResult的标准返回值存放到FileVisitResult枚举类型中：FileVisitResult.CONTINUE : 这个访问结果表示当前的遍历过程将会继续。 FileVisitResult.SKIP SIBLINGS :这个访问结果表示当前的遍历过程将会继续，但是要忽略当前文件/目录的兄弟节点。FileVisitResult.SKIP SUBTREE : 这个访问结果表示当前的遍历过程将会继续，但是要忽略当前目录下的所有节点。FileVisitResult.TERMINATE : 这个访问结果表示当前的遍历过程将会停止。public interface FileVisitor<T> { FileVisitResult preVisitDirectory(T dir, BasicFileAttributes attrs) throws IOException; FileVisitResult visitFile(T file, BasicFileAttributes attrs) throws IOException; FileVisitResult visitFileFailed(T file, IOException exc) throws IOException; FileVisitResult postVisitDirectory(T dir, IOException exc) throws IOException; }通过它去遍历文件树会比较方便，比如查找文件夹内符合某个条件的文件或者某一天内所创建的文件，这个类中都提供了相对应的方法。我们来看一下它的实现其实也非常简单:public class SimpleFileVisitor<T> implements FileVisitor<T> { protected SimpleFileVisitor() { } @Override public FileVisitResult preVisitDirectory(T dir, BasicFileAttributes attrs) throws IOException { Objects.requireNonNull(dir); Objects.requireNonNull(attrs); return FileVisitResult.CONTINUE; } @Override public FileVisitResult visitFile(T file, BasicFileAttributes attrs) throws IOException { Objects.requireNonNull(file); Objects.requireNonNull(attrs); return FileVisitResult.CONTINUE; } @Override public FileVisitResult visitFileFailed(T file, IOException exc) throws IOException { Objects.requireNonNull(file); throw exc; } @Override public FileVisitResult postVisitDirectory(T dir, IOException exc) throws IOException { Objects.requireNonNull(dir); if (exc != null) throw exc; return FileVisitResult.CONTINUE; } }下面再来看访问者模式在Spring中的应用, Spring loC中有个BeanDefinitionVisitor类 , 其中有一个visitBeanDefinitionO方 法 ,我们来看他的源码:public class BeanDefinitionVisitor { @Nullable private StringValueResolver valueResolver; public BeanDefinitionVisitor(StringValueResolver valueResolver) { Assert.notNull(valueResolver, "StringValueResolver must not be null"); this.valueResolver = valueResolver; } protected BeanDefinitionVisitor() { } public void visitBeanDefinition(BeanDefinition beanDefinition) { visitParentName(beanDefinition); visitBeanClassName(beanDefinition); visitFactoryBeanName(beanDefinition); visitFactoryMethodName(beanDefinition); visitScope(beanDefinition); if (beanDefinition.hasPropertyValues()) { visitPropertyValues(beanDefinition.getPropertyValues()); } if (beanDefinition.hasConstructorArgumentValues()) { ConstructorArgumentValues cas = beanDefinition.getConstructorArgumentValues(); visitIndexedArgumentValues(cas.getIndexedArgumentValues()); visitGenericArgumentValues(cas.getGenericArgumentValues()); } } }我们看到在visitBeanDefinition方法中,分别访问了其他的数据，比如父类的名字、自己 的类名、在 loC容器中的名称等各种信息。22.5.解释器模式的优缺点优点：1、 解耦了数据结构与数据操作，使得操作集合可以独立变化；2、 扩展性好：可以通过扩展访问者角色，实现对数据集的不同操作；3、 元素具体类型并非单一，访问者均可操作；4、 各角色职责分离，符合单一职责原则。缺点：1、无法增加元素类型：若系统数据结构对象易于变化，经常有新的数据对象增加进来，则访问者类必须增加对应元素类型的操作，违背了开闭原则；2、具体元素变更困难：具体元素增加属性，删除属性等操作会导致对应的访问者类需要进行相应的修改，尤其当有大量访问者类时，修改范围太大；3、违背依赖倒置原则：为了达到" 区别对待〃,访问者依赖的是具体元素类型，而不是抽象。22.6.思维导图22.7.作业1、用Guava API实现GPer社区提问通知的业务场景。2、说说你理解的访问者模式的精髓是什么？

5.原型模式5.1.课程目标1、掌握原型模式和建造者模式的应用场景2、掌握原型模式的浅克隆和深克隆的写法。3、掌握建造者模式的基本写法。4、了解克隆是如何破坏单例的。5、了解原型模式的优、缺点6、掌握建造者模式和工厂模式的区别。5.2.内容定位1、已了解并掌握工厂模式的人群。2、已了解并掌握单例模式。3、听说过原型模式，但不知道应用场景的人群。5.3.定义原型模式（PrototypePattern）是指原型实例指定创建对象的种类，并且通过拷贝这些原型创建新的对象，属于创建型模式。官方原文：Specify the kinds of objects to create using a prototypical instance,and create new objects by copying this prototype.原型模式的核心在于拷贝原型对象。以系统中已存在的一个对象为原型，直接基于内存二进制流进行拷贝，无需再经历耗时的对象初始化过程（不调用构造函数），性能提升许多。当对象的构建过程比较耗时时，可以利用当前系统中已存在的对象作为原型，对其进行克隆（一般是基于二进制流的复制），躲避初始化过程，使得新对象的创建时间大大减少。下面，我们来看看原型模式类结构图：从 UML 图中，我们可以看到，原型模式 主要包含三个角色：客户(Client)：客户类提出创建对象的请求。抽象原型(Prototype)：规定拷贝接口。具体原型（Concrete Prototype）：被拷贝的对象。注：对不通过 new 关键字，而是通过对象拷贝来实现创建对象的模式就称作原型模式。5.4.原型模式的应用场景你一定遇到过大篇幅getter、setter赋值的场景。代码非常工整，命名非常规范，注释也写的很全面,其实这就是原型模式的需求场景。但是，大家觉得这样的代码优雅吗？我认为，这样的代码属于纯体力劳动。那原型模式，能帮助我们解决这样的问题。原型模式主要适用于以下场景：1、类初始化消耗资源较多。2、new产生的一个对象需要非常繁琐的过程（数据准备、访问权限等）3、构造函数比较复杂。4、循环体中生产大量对象时。在 Spring 中，原型模式应用得非常广泛。例如 scope=“prototype”，在我们经常用的JSON.parseObject()也是一种原型模式。5.5.原型模式的通用写法（浅拷贝）一个标准的原型模式代码，应该是这样设计的。先创建原型IPrototype接口：public interface IPrototype<T> { T clone(); }创建具体需要克隆的对象ConcretePrototypepublic class ConcretePrototype implements IPrototype { private int age; private String name; public int getAge() { return age; } public void setAge(int age) { this.age = age; } public String getName() { return name; } public void setName(String name) { this.name = name; } @Override public ConcretePrototype clone() { ConcretePrototype concretePrototype = new ConcretePrototype(); concretePrototype.setAge(this.age); concretePrototype.setName(this.name); return concretePrototype; } @Override public String toString() { return "ConcretePrototype{" + "age=" + age + ", name='" + name + '\'' + '}'; } }测试代码：public class Client { public static void main(String[] args) { //创建原型对象 ConcretePrototype prototype = new ConcretePrototype(); prototype.setAge(18); prototype.setName("Tom"); System.out.println(prototype); //拷贝原型对象 ConcretePrototype cloneType = prototype.clone(); System.out.println(cloneType); } }运行结果：ConcretePrototype{age=18, name='Tom'} ConcretePrototype{age=18, name='Tom'}这时候，有小伙伴就问了，原型模式就这么简单吗？对，就是这么简单。在这个简单的场景之下，看上去操作好像变复杂了。但如果有几百个属性需要复制，那我们就可以一劳永逸。但是，上面的复制过程是我们自己完成的，在实际编码中，我们一般不会浪费这样的体力劳动，JDK已经帮我们实现了一个现成的API，我们只需要实现Cloneable接口即可。来改造一下代码，修改ConcretePrototype类：@Data public class ConcretePrototype implements Cloneable { private int age; private String name; @Override public ConcretePrototype clone() { try { return (ConcretePrototype)super.clone(); } catch (CloneNotSupportedException e) { e.printStackTrace(); return null; } } }重新运行，也会得到同样的结果。有了JDK的支持再多的属性复制我们也能轻而易举地搞定了。下面我们再来做一个测试，给ConcretePrototype增加一个个人爱好的属性hobbies：@Data public class ConcretePrototype implements Cloneable { private int age; private String name; private List<String> hobbies; @Override public ConcretePrototype clone() { try { return (ConcretePrototype)super.clone(); } catch (CloneNotSupportedException e) { e.printStackTrace(); return null; } } }修改客户端测试代码：public class Client { public static void main(String[] args) { //创建原型对象 ConcretePrototype prototype = new ConcretePrototype(); prototype.setAge(18); prototype.setName("Tom"); List<String> hobbies = new ArrayList<String>(); hobbies.add("书法"); hobbies.add("美术"); prototype.setHobbies(hobbies); //拷贝原型对象 ConcretePrototype cloneType = prototype.clone(); cloneType.getHobbies().add("技术控"); System.out.println("原型对象：" + prototype); System.out.println("克隆对象：" + cloneType); System.out.println(prototype == cloneType); System.out.println("原型对象的爱好：" + prototype.getHobbies()); System.out.println("克隆对象的爱好：" + cloneType.getHobbies()); System.out.println(prototype.getHobbies() == cloneType.getHobbies()); } }运行结果：原型对象：ConcretePrototype(age=18, name=Tom, hobbies=[书法, 美术, 技术控]) 克隆对象：ConcretePrototype(age=18, name=Tom, hobbies=[书法, 美术, 技术控]) false 原型对象的爱好：[书法, 美术, 技术控] 克隆对象的爱好：[书法, 美术, 技术控] true我们给，复制后的克隆对象新增一项爱好，发现原型对象也发生了变化，这显然不符合我们的预期。因为我们希望克隆出来的对象应该和原型对象是两个独立的对象，不应该再有联系了。从测试结果分析来看，应该是hobbies共用了一个内存地址，意味着复制的不是值，而是引用的地址。这样的话，如果我们修改任意一个对象中的属性值，prototype 和cloneType的hobbies值都会改变。这就是我们常说的浅克隆。只是完整复制了值类型数据，没有赋值引用对象。换言之，所有的引用对象仍然指向原来的对象，显然不是我们想要的结果。那如何解决这个问题呢？下面我们来看深度克隆继续改造。扩展知识：String对象在内存中是不可变的（final类型），虽然克隆后，两个对象String的引用指向的是同一个内存地址，但是如果给克隆后的对象的String属性改变值，那么相当于是在内存中重新开辟了一块内存来存储这个改变的值，而此时的String属性对象就指向了该内存值，所以这个时候克隆前和克隆后对象的String属性是不一样的）。String 每次赋值，相当于new String()。5.6.使用序列化实现深度克隆在上面的基础上我们继续改造，来看代码，增加一个deepClone()方法：@Data public class ConcretePrototype implements Cloneable,Serializable { private int age; private String name; private List<String> hobbies; @Override public ConcretePrototype clone() { try { return (ConcretePrototype)super.clone(); } catch (CloneNotSupportedException e) { e.printStackTrace(); return null; } } public ConcretePrototype deepClone(){ try { ByteArrayOutputStream bos = new ByteArrayOutputStream(); ObjectOutputStream oos = new ObjectOutputStream(bos); oos.writeObject(this); ByteArrayInputStream bis = new ByteArrayInputStream(bos.toByteArray()); ObjectInputStream ois = new ObjectInputStream(bis); return (ConcretePrototype)ois.readObject(); }catch (Exception e){ e.printStackTrace(); return null; } } }来看客户端调用代码：public class Client { public static void main(String[] args) { //创建原型对象 ConcretePrototype prototype = new ConcretePrototype(); prototype.setAge(18); prototype.setName("Tom"); List<String> hobbies = new ArrayList<String>(); hobbies.add("书法"); hobbies.add("美术"); prototype.setHobbies(hobbies); //拷贝原型对象 ConcretePrototype cloneType = prototype.deepClone(); cloneType.getHobbies().add("技术控"); System.out.println("原型对象：" + prototype); System.out.println("克隆对象：" + cloneType); System.out.println(prototype == cloneType); System.out.println("原型对象的爱好：" + prototype.getHobbies()); System.out.println("克隆对象的爱好：" + cloneType.getHobbies()); System.out.println(prototype.getHobbies() == cloneType.getHobbies()); } }运行程序，我们发现得到了我们期望的结果：原型对象：ConcretePrototype(age=18, name=Tom, hobbies=[书法, 美术]) 克隆对象：ConcretePrototype(age=18, name=Tom, hobbies=[书法, 美术, 技术控]) false 原型对象的爱好：[书法, 美术] 克隆对象的爱好：[书法, 美术, 技术控] false5.7.克隆破坏单例模式如果我们克隆的目标的对象是单例对象，那意味着，深克隆就会破坏单例。实际上防止克隆破坏单例解决思路非常简单，禁止深克隆便可。要么你我们的单例类不实现 Cloneable 接口；要么我们重写clone()方法，在clone方法中返回单例对象即可，具体代码如下：@Override protected Object clone() throws CloneNotSupportedException { return INSTANCE; }5.8.原型模式在源码中的应用先来JDK中Cloneable接口：public interface Cloneable { }接口定义还是很简单的，我们找源码其实只需要找到看哪些接口实现了 Cloneable 即可。来看ArrayList类的实现。Object方法protected native Object clone() throws CloneNotSupportedException;ArrayList是实现的clone方法public class ArrayList<E> extends AbstractList<E> implements List<E>, RandomAccess, Cloneable, java.io.Serializable { public Object clone() { try { ArrayList<?> v = (ArrayList<?>) super.clone(); v.elementData = Arrays.copyOf(elementData, size); v.modCount = 0; return v; } catch (CloneNotSupportedException e) { // this shouldn't happen, since we are Cloneable throw new InternalError(e); } } }我们发现方法中只是将List中的元素循环遍历了一遍。这个时候我们再思考一下，是不是这种形式就是深克隆呢？其实用代码验证一下就知道了，继续修改 ConcretePrototype 类，增加一个deepCloneHobbies()方法：@Data public class ConcretePrototype implements Cloneable,Serializable { ... public ConcretePrototype deepCloneHobbies(){ try { ConcretePrototype result = (ConcretePrototype)super.clone(); result.hobbies = (List)((ArrayList)result.hobbies).clone(); return result; } catch (CloneNotSupportedException e) { e.printStackTrace(); return null; } } ... }修改客户端代码：public class Client { public static void main(String[] args) { ... //拷贝原型对象 ConcretePrototype cloneType = prototype.deepCloneHobbies(); ... } }运行也能得到期望的结果。但是这样的代码，其实是硬编码，如果在对象中声明了各种集合类型，那每种情况都需要单独处理。因此，深克隆的写法，一般会直接用序列化来操作。5.9.原型模式的优缺点优点:1、性能优良，Java自带的 原型模式 是基于内存二进制流的拷贝，比直接new一个对象性能上提升了许多。2、可以使用深克隆方式保存对象的状态，使用原型模式将对象复制一份并将其状态保存起来，简化了创建对象的过程，以便在需要的时候使用(例如恢复到历史某一状态)，可辅助实现撤销操作。缺点：1、需要为每一个类配置一个克隆方法。2、克隆方法位于类的内部，当对已有类进行改造的时候，需要修改代码，违反了开闭原则。3、在实现深克隆时需要编写较为复杂的代码，而且当对象之间存在多重嵌套引用时，为了实现深克隆，每一层对象对应的类都必须支持深克隆，实现起来会比较麻烦。因此，深拷贝、浅拷贝需要运用得当。6.0总结克隆方式：1.序列化 反序列化 2.jsonobject 3浅克隆加赋值浅克隆：继承Cloneable接口的都是浅克隆。深克隆两种方式：序列化，转JSON。6.建造者模式6.1.定义建造者模式（Builder Pattern）是将一个复杂对象的构建过程与它的表示分离，使得同样的构建过程可以创建不同的表示，属于创建型模式。使用建造者模式对于用户而言只需指定需要建造的类型就可以获得对象，建造过程及细节不需要了解。官方原文：Separate the construction of a complex object from its representation so that the same construction process can create different representations.建造者模式适用于创建对象需要很多步骤，但是步骤的顺序不一定固定。如果一个对象有非常复杂的内部结构（很多属性），可以将复杂对象的创建和使用进行分离。先来看一下建造者模式的类图：建造者模式的设计中主要有四个角色：1、产品（Product）:要创建的产品类对象2、建造者抽象（Builder）：建造者的抽象类，规范产品对象的各个组成部分的建造，一般由子类实现具体的建造过程。3、建造者（ConcreteBuilder）:具体的Builder类，根据不同的业务逻辑，具体化对象的各个组成部分的创建。4、调用者（Director）：调用具体的建造者，来创建对象的各个部分，在指导者中不涉及具体产品的信息，只负责保证对象各部分完整创建或按某种顺序创建。6.2.建造者模式的应用场景建造者模式适用于一个具有较多的零件的复杂产品的创建过程，由于需求的变化，组成这个复杂产品的各个零件经常猛烈变化，但是它们的组合方式却相对稳定。相同的方法，不同的执行顺序，产生不同的结果时多个部件或零件，都可以装配到一个对象中，但是产生的结果又不相同。产品类非常复杂，或者产品类中的调用顺序不同产生不同的作用。当初始化一个对象特别复杂，参数多，而且很多参数都具有默认值时。建造者模式，只关注用户需要什么，将最少的关键字传过来，生成你想要的结果。实际顺序是在build方法里面。那是顺序和条件都确定了。每个顺序和条件都分别存储下来了。判断有没有，有就添加到product后面。当然就是先判断条件再判断order顺序了6.3.建造者模式的基本写法我们还是以课程为例，一个完整的课程需要由PPT课件、回放视频、课堂笔记、课后作业组成，但是这些内容的设置顺序可以随意调整，我们用建造者模式来代入理解一下。首先我们创建一个需要构造的产品类Course：@Data public class Course { private String name; private String ppt; private String video; private String note; private String homework; }然后创建建造者类CourseBuilder，将复杂的构造过程封装起来，构造步骤由用户决定：public class CourseBuilder{ private Course course = new Course(); public void addName(String name) { course.setName(name); } public void addPPT(String ppt) { course.setPpt(ppt); } public void addVideo(String video) { course.setVideo(video); } public void addNote(String note) { course.setNote(note); } public void addHomework(String homework) { course.setHomework(homework); } public Course build() { return course; } }编写测试类：public class Test { public static void main(String[] args) { CourseBuilder builder = new CourseBuilder(); builder.addName("设计模式"); builder.addPPT("【PPT课件】"); builder.addVideo("【回放视频】"); builder.addNote("【课堂笔记】"); builder.addHomework("【课后作业】"); System.out.println(builder.build()); } }运行结果:Course(name=设计模式, ppt=【PPT课件】, video=【回放视频】, note=【课堂笔记】, homework=【课后作业】)来看一下类结构图：6.4.建造者模式的链式写法在平时的应用中，建造者模式通常是采用链式编程的方式构造对象，下面我们来一下演示代码，修改CourseBuilder类，将Course变为CourseBuilder的内部类。然后，将构造步骤添加进去，每完成一个步骤，都返回this：public class CourseBuilder { private Course course = new Course(); public CourseBuilder addName(String name) { course.setName(name); return this; } public CourseBuilder addPPT(String ppt) { course.setPpt(ppt); return this; } public CourseBuilder addVideo(String video) { course.setVideo(video); return this; } public CourseBuilder addNote(String note) { course.setNote(note); return this; } public CourseBuilder addHomework(String homework) { course.setHomework(homework); return this; } public Course build() { return this.course; } @Data public class Course { private String name; private String ppt; private String video; private String note; private String homework; } }客户端使用：public class Test { public static void main(String[] args) { CourseBuilder builder = new CourseBuilder() .addName("设计模式") .addPPT("【PPT课件】") .addVideo("【回放视频】") .addNote("【课堂笔记】") .addHomework("【课后作业】"); System.out.println(builder.build()); } }这样写法是不是很眼熟，好像在哪见过呢？后面我们分析建造者模式在源码中的应用大家就会明白。接下来，我们再来看一下类图的变化：6.5.建造者模式应用案例下面我们再来看一个实战案例，这个案例参考了开源框架JPA的SQL构造模式。是否记得我们在构造SQL查询条件的时候，需要根据不同的条件来拼接SQL字符串。如果查询条件复杂的时候，我们SQL拼接的过程也会变得非常复杂，从而给我们的代码维护带来非常大的困难。因此，我们用建造者类QueryRuleSqlBuilder 将复杂的构造 SQL 过程进行封装，用 QueryRule 对象专门保存 SQL 查询时的条件，最后根据查询条件，自动生成SQL语句。来看代码，先创建QueryRule类：/** * QueryRule,主要功能用于构造查询条件 */ public final class QueryRule implements Serializable { ... /** * 添加升序规则 * @param propertyName * @return */ public QueryRule addAscOrder(String propertyName) { this.ruleList.add(new Rule(ASC_ORDER, propertyName)); return this; } public QueryRule andEqual(String propertyName, Object value) { this.ruleList.add(new Rule(EQ, propertyName, new Object[] { value }).setAndOr(AND)); return this; } public QueryRule andLike(String propertyName, Object value) { this.ruleList.add(new Rule(LIKE, propertyName, new Object[] { value }).setAndOr(AND)); return this; } ... }然后，创建QueryRuleSqlBuilder类：/** * 根据QueryRule自动构建sql语句 */ public class QueryRuleSqlBuilder { ... /** * 处理like * @param rule */ private void processLike(QueryRule.Rule rule) { if (ArrayUtils.isEmpty(rule.getValues())) { return; } Object obj = rule.getValues()[0]; if (obj != null) { String value = obj.toString(); if (!StringUtils.isEmpty(value)) { value = value.replace('*', '%'); obj = value; } } add(rule.getAndOr(),rule.getPropertyName(),"like","%"+rule.getValues()[0]+"%"); } /** * 处理 = * @param rule */ private void processEqual(QueryRule.Rule rule) { if (ArrayUtils.isEmpty(rule.getValues())) { return; } add(rule.getAndOr(),rule.getPropertyName(),"=",rule.getValues()[0]); } /** * 处理 order by * @param rule 查询规则 */ private void processOrder(Rule rule) { switch (rule.getType()) { case QueryRule.ASC_ORDER: // propertyName非空 if (!StringUtils.isEmpty(rule.getPropertyName())) { orders.add(Order.asc(rule.getPropertyName())); } break; case QueryRule.DESC_ORDER: // propertyName非空 if (!StringUtils.isEmpty(rule.getPropertyName())) { orders.add(Order.desc(rule.getPropertyName())); } break; default: break; } } ... }创建Order类：/** * sql排序组件 */ public class Order { private boolean ascending; //升序还是降序 private String propertyName; //哪个字段升序，哪个字段降序 public String toString() { return propertyName + ' ' + (ascending ? "asc" : "desc"); } /** * Constructor for Order. */ protected Order(String propertyName, boolean ascending) { this.propertyName = propertyName; this.ascending = ascending; } /** * Ascending order * * @param propertyName * @return Order */ public static Order asc(String propertyName) { return new Order(propertyName, true); } /** * Descending order * * @param propertyName * @return Order */ public static Order desc(String propertyName) { return new Order(propertyName, false); } }编写测试代码：public class Test { public static void main(String[] args) { QueryRule queryRule = QueryRule.getInstance(); queryRule.addAscOrder("age"); queryRule.andEqual("addr","Changsha"); queryRule.andLike("name","Tom"); QueryRuleSqlBuilder builder = new QueryRuleSqlBuilder(queryRule); System.out.println(builder.builder("t_member")); System.out.println("Params: " + Arrays.toString(builder.getValues())); } }这样一来，我们的客户端代码就非常清朗，来看运行结果：select * from t_member where addr = ? and name like ? order by age asc Params: [Changsha, %Tom%]6.6.建造者模式在源码中的体现下面来看建造者模式在哪些源码中有应用呢？首先来看JDK的StringBuilder，它提供append()方法，给我们开放构造步骤，最后调用toString()方法就可以获得一个构造好的完整字符串，源码如下：public final class StringBuilder extends AbstractStringBuilder implements java.io.Serializable, CharSequence { public StringBuilder append(StringBuffer sb) { super.append(sb); return this; } }在MyBatis中也有体现，比如CacheBuilder类。同样在 MyBatis 中，比如 SqlSessionFactoryBuilder 通过调用 build()方法获得的是一个SqlSessionFactory 类。当然，在 Spring中自然也少不了，比如 BeanDefinitionBuilder 通过调用getBeanDefinition()方法获得一个BeanDefinition对象。6.7.建造者模式的优缺点建造者模式的优点：1、封装性好，创建和使用分离；2、扩展性好，建造类之间独立、一定程度上解耦。建造者模式的缺点：1、产生多余的Builder对象；2、产品内部发生变化，建造者都要修改，成本较大。6.8.建造者模式和工厂模式的区别建造者模式和工厂模式的区别1、建造者模式更加注重方法的调用顺序，工厂模式注重于创建对象。2、创建对象的力度不同，建造者模式创建复杂的对象，由各种复杂的部件组成，工厂模式创建出来的都一样。3、关注重点不一样，工厂模式模式只需要把对象创建出来就可以了，而建造者模式中不仅要创建出这个对象，还要知道这个对象由哪些部件组成。4、建造者模式根据建造过程中的顺序不一样，最终的对象部件组成也不一样。可以理解为工厂创建过程是静态的，构建者模式创建过程经过外放而变成动态的。6.9.总结[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-6NvWlHZp-1630251881056)(https://gitee.com/woshiamiaojiang/image-hosting/raw/master/image-20200229231653673.png)]7.0.作业1.用JSON方式实现一个原型模式的深克隆，并画出UML图。一行代码，比IO流简单。public ConcretePrototype deepCloneByJSON(){ try { return JSON.parseObject(JSON.toJSONString(this), ConcretePrototype.class); }catch (Exception e){ e.printStackTrace(); return null; } }2.请列举1-3个需要用到建造者模式的业务场景。建造者模式：适用于对象创建需要动态拼接复杂属性值的业务场景。例如：SQL拼接，链式编程，NIO。

16.策略模式16.1.课程目标1、 掌握策略模式和责任链模式的应用场景；2、 通过学习策略模式来消除程序中大量的if...else...和 switch语 句 ;3、 掌握策略模式和委派模式的结合使用；4、 深刻理解责任链模式和建造者模式的结合应用16.2.内容定位1 、已经掌握建造者模式和委质模式的人群。2、希望通过对策略模式的学习，来消除程序中大量的冗余代码和多重条件转移语句的人群。3、希望通过学习责任链模式宜构校验逻辑的人群。16.3.定义策略模式 (Strategy Pattern) 又叫也叫政策摆式 (Policy Pattern) , 它是将定义的算法家族、分别封装起来，让它们之间可以互相替换，从而让算法的变化不会影响到使用算法的用户。属千行为型模式。原 文： Define a family of algorithms,encapsulate each one,and make them interchangeable.策略摆式使用的就是面向对象的继承和多态机制，从而实现同—行为在不同场萦下具备不同实现。16.4.应用场景策略模式在生活场景中应用也非常多。比如—个入的交税比率与他的工资有关，不同的工资水平对应不同的税率。再比如我们在互联网移动支付的大背景下，每次下单后付款前，需要选择支付方式。策略模式可以解决在有多种算法相似的情况下，使用 if…else 或 switch... case 所带来的复杂性和臃肿性。在日常业务开发中，策略模式适用于以下场景 ：1 、针对同—类型问题，有多种处理方式，每—种都能独立解决问题 ；2、 算法需要自由切换的场果 ；3、需要屏蔽算法规则的场果。首先来看下策略模式的通用 UML 类图 ：从 UML 类图中，我们可以看到，策略摆式主要包含三种角色 ：上下文角色 (Context) : 用来操作策略的上下文环境，屏蔽高层模块（客户端）对策略， 算法的直接访问，封装可能存在的变化 ；抽象策略角色 (Strategy) : 规定策略或算法的行为 ；具体策略角色 (ConcreteStrategy) : 具体的策略或算法实现。注意： 策略模式中的上下文环境 (Context) , 其职责本来是隔离客户端与策略类的耦合， 让客户端完全与上下文环境 沟通， 无需关系具体策略。16.5.促销优惠业务场景优惠策略会有很多种可能如 ： 领取优惠券抵扣、返现促销、拼团优惠。下面我们用代码来模拟，首先我们创建—个促销策略的抽象PromotionStrategy :/** * 促销策略抽象 */ public interface IPromotionStrategy { void doPromotion(); }然后分别创建优惠券抵扣策略 CouponStrategy 类、返现促销策略 CashbackStrategy 类、拼团优惠策略 GroupbuyStrategy 类和无优惠策略 EmptyStrategy 类 ：public class CouponStrategy implements IPromotionStrategy { public void doPromotion() { System.out.println("使用优惠券抵扣"); } }CashbackStrategy 类 ：public class CashbackStrategy implements IPromotionStrategy { public void doPromotion() { System.out.println("返现，直接打款到支付宝账号"); } }GroupbuyStrategy 类 ：public class GroupbuyStrategy implements IPromotionStrategy { public void doPromotion() { System.out.println("5人成团，可以优惠"); } }EmptyStrategy 类 ：public class EmptyStrategy implements IPromotionStrategy { public void doPromotion() { System.out.println("无优惠"); } }然后创建促销活动方案 PromotionActivity 类 ：public class PromotionActivity { private IPromotionStrategy strategy; public PromotionActivity(IPromotionStrategy strategy) { this.strategy = strategy; } public void execute(){ strategy.doPromotion(); } }编写客户端测试类 ：public class Test { public static void main(String[] args) { PromotionActivity activity618 = new PromotionActivity(new CouponStrategy()); PromotionActivity activityllll = new PromotionActivity(new CashbackStrategy()); activity618.execute(); activityllll.execute(); } }运行效果如下：使用优惠券抵扣 返现，直接打款到支付宝账号此时，小伙伴们会发现，如果把上面这段则试代码放到实际的业务场景其实并不实用。因为我们做活动时候往往是要根据不同的需求对促销策略进行动态选择的，并不会一次性执行多种优惠。所以，我们的代码通常会这样写 ：public class Test { public static void main(String[] args) { PromotionActivity promotionActivity = null; String promotionKey = "COUPON"; if (StringUtils.equals(promotionKey, "COUPON")) { promotionActivity = new PromotionActivity(new CouponStrategy()); } else if (StringUtils.equals(promotionKey, "CASHBACK")) { promotionActivity = new PromotionActivity(new CashbackStrategy()); } promotionActivity.execute(); } }这样改造之后，满足了业务需求，客户可根据自己的需求选择不同的优惠策略了。但是，经过—段时间的业务积累，我们的促销活动会越来越多。千是，我们的程序猿小哥哥就忙不来了，每次上活动之前都要通宵改代码，而且要做重复测试，判断逻辑可能也变得越来越复杂。这时候，我们是不需要思考代码是不是应该重构了？回顾我们之前学过的设计模式应该如何来优化这段代码呢？其实，我们可以结合单例模式和工厂摆式。创建 PromotionStrategyFactory 类 ：public class PromotionStrategyFacory { private static final IPromotionStrategy EMPTY = new EmptyStrategy(); private static Map<String, IPromotionStrategy> PROMOTIONS = new HashMap<String, IPromotionStrategy>(); static { PROMOTIONS.put(PromotionKey.COUPON, new CouponStrategy()); PROMOTIONS.put(PromotionKey.CASHBACK, new CashbackStrategy()); PROMOTIONS.put(PromotionKey.GROUPBUY, new GroupbuyStrategy()); } private PromotionStrategyFacory() { } public static IPromotionStrategy getPromotionStrategy(String promotionKey) { IPromotionStrategy strategy = PROMOTIONS.get(promotionKey); return strategy == null ? EMPTY : strategy; } public static Set<String> getPromotionKeys() { return PROMOTIONS.keySet(); } private interface PromotionKey { String COUPON = "COUPON"; String CASHBACK = "CASHBACK"; String GROUPBUY = "GROUPBUY"; } }这时候我们客户端代码就应该这样写了 ：public class Test { public static void main(String[] args) { PromotionActivity activity618 = new PromotionActivity(new CouponStrategy()); PromotionActivity activityllll = new PromotionActivity(new CashbackStrategy()); activity618.execute(); activityllll.execute(); } }运行效果如下：使用优惠券抵扣代码优化之后 ， 是不是我们程序猿小哥哥的维护工作就轻松了？每次上新活动，不影响原来的代码逻辑。16.6.用策略模式实现选择支付方式的业务场景为了加深对策略模式的理解，我们再来举一个案例。 相信小伙伴们都用过支付宝、微信支付、银联支付以及京东白条。 —个常见的应用场景就是大家在下单支付时会提示选择支付方式，如果用户未选，系统也会默认好推荐的支付方式进行结算。来看一下类图，下面我们用策略模式来描拟此业务场罢 ：创建 Payment 抽象类，定义支付规范和支付逻辑，代码如下 ：public abstract class Payment { public abstract String getName(); //通用逻辑放到抽象类里面实现 public MsgResult pay(String uid, double amount) { //余额是否足够 if (queryBalance(uid) < amount) { return new MsgResult(500, "支付失败", "余额不足"); } return new MsgResult(200, "支付成功", "支付金额" + amount); } protected abstract double queryBalance(String uid); }分别创建具体的支付方式，支付宝 AliPay类 ：public class AliPay extends Payment { public String getName() { return "支付宝"; } protected double queryBalance(String uid) { return 900; } }京东白条JDPay 类 ：public class JDPay extends Payment { public String getName() { return "京东白条"; } protected double queryBalance(String uid) { return 500; } } 微信支付 WechatPay类 ：public class WechatPay extends Payment { public String getName() { return "微信支付"; } protected double queryBalance(String uid) { return 263; } }银联支付 UnionPay 类 ：public class UnionPay extends Payment { public String getName() { return "银联支付"; } protected double queryBalance(String uid) { return 120; } }创建支付状态的包装类 MsgResult:public class MsgResult { private int code; private Object data; private String msg; public MsgResult(int code, String msg, Object data) { this.code = code; this.data = data; this.msg = msg; } @Override public String toString() { return "MsgResult{" + "code=" + code + ", data=" + data + ", msg='" + msg + '\'' + '}'; } }创建支付策略管理类 ：public class PayStrategy { public static final String ALI_PAY = "AliPay"; public static final String JD_PAY = "JdPay"; public static final String WECHAT_PAY = "WechatPay"; public static final String UNION_PAY = "UnionPay"; public static final String DEFAULT_PAY = ALI_PAY; private static Map<String,Payment> strategy = new HashMap<String,Payment>(); static { strategy.put(ALI_PAY,new AliPay()); strategy.put(JD_PAY,new JDPay()); strategy.put(WECHAT_PAY,new WechatPay()); strategy.put(UNION_PAY,new UnionPay()); } public static Payment get(String payKey){ if(!strategy.containsKey(payKey)){ return strategy.get(DEFAULT_PAY); } return strategy.get(payKey); } }创建订单 Order 类 ：public class Order { private String uid; private String orderId; private double amount; public Order(String uid, String orderId, double amount) { this.uid = uid; this.orderId = orderId; this.amount = amount; } public MsgResult pay(){ return pay(PayStrategy.DEFAULT_PAY); } public MsgResult pay(String payKey){ Payment payment = PayStrategy.get(payKey); System.out.println("欢迎使用" + payment.getName()); System.out.println("本次交易金额为" + amount + "，开始扣款"); return payment.pay(uid,amount); } }测试代码 ：public class Test { public static void main(String[] args) { Order order = new Order("1","2020031401000323",324.5); System.out.println(order.pay(PayStrategy.UNION_PAY)); } }运行结果 ：欢迎使用银联支付 本次交易金额为324.5，开始扣款 MsgResult{code=500, data=余额不足, msg='支付失败'}希望通过大家耳熟能详的业务场景来举例，让小伙伴们更深刻地理解策略模式。希望小伙伴们在面试和工作体现出自己的优势。16.7.策略模式在框架源码中的体现首先来看JDK 中—个比较常用的比较器 Comparator 接口，我们看到的—个大家常用的 compare()方法，就是一个策略抽象实现 ：public interface Comparator<T> { int compare(T o1, T o2); }Comparator抽象下面有非常多的实现类，我们经常会把 Comparator作为参数传入作为排序策略，例如 Arrays 类的 parallelSort 方法等 ：public class Arrays { public static void parallelSort(byte[] a) { int n = a.length, p, g; if (n <= MIN_ARRAY_SORT_GRAN || (p = ForkJoinPool.getCommonPoolParallelism()) == 1) DualPivotQuicksort.sort(a, 0, n - 1); else new ArraysParallelSortHelpers.FJByte.Sorter (null, a, new byte[n], 0, n, 0, ((g = n / (p << 2)) <= MIN_ARRAY_SORT_GRAN) ? MIN_ARRAY_SORT_GRAN : g).invoke(); } }还有 TreeMap 的构造方法：public class TreeMap<K,V> extends AbstractMap<K,V> implements NavigableMap<K,V>, Cloneable, java.io.Serializable { public TreeMap(Comparator<? super K> comparator) { this.comparator = comparator; } }这就是 Comparator 在JDK原码中的应用。那我们来看策略模式在 Spring源码中的应用，来看Resource 类 ：public interface Resource extends InputStreamSource { boolean exists(); default boolean isReadable() { return true; } default boolean isOpen() { return false; } default boolean isFile() { return false; } URL getURL() throws IOException; URI getURI() throws IOException; File getFile() throws IOException; default ReadableByteChannel readableChannel() throws IOException { return Channels.newChannel(this.getInputStream()); } long contentLength() throws IOException; long lastModified() throws IOException; Resource createRelative(String var1) throws IOException; @Nullable String getFilename(); String getDescription(); }我们虽然没有直接使用 Resource 类，但是我们经常使用它的子类，例如 ：/* * @see WritableResource * @see ContextResource * @see UrlResource * @see ClassPathResource * @see FileSystemResource * @see PathResource * @see ByteArrayResource * @see InputStreamResource */还有一个非常典型的场罢， Spring 的初始化也采用了策略模式，不同的类型的类采用不同的初始化策略。首先有一个 lnstantiationStrategy 接口，我们来看一下涌码 ：public interface InstantiationStrategy { Object instantiate(RootBeanDefinition bd, @Nullable String beanName, BeanFactory owner) throws BeansException; Object instantiate(RootBeanDefinition bd, @Nullable String beanName, BeanFactory owner, Constructor<?> ctor, @Nullable Object... args) throws BeansException; Object instantiate(RootBeanDefinition bd, @Nullable String beanName, BeanFactory owner, @Nullable Object factoryBean, Method factoryMethod, @Nullable Object... args) throws BeansException; }顶层的策略抽象非常简单，但是它下面有两种策略 SimplelnstantiationStrategy 和CgIibSubclassingInsta ntiationStrategy , 我们看—下类图 ：打开类图我们还发现 CgIibSubclassingInstantiationStrategy 策略类还继承了SimplelnstantiationStrategy 类，说明在实际应用中多种策略之间还可以继承使用。小伙们可以作为—个参考，在实际业务场萦中，可以根据需要来设计。16.8.策略模式的优缺点优点 ：1 、策略模式符合开闭原则。2、避免使用多重条件转移语句，如 if…else.. 语句、 switch 语句3、使用策略模式可以提高算法的保密性和安全性。缺点 ：1 、客户端必须知道所有的策略，并且自行决定使用哪一个策略类。2、代码中会产生非常多策略类，增加维护难度。17.责任链模式责任链模式 (Chain of Responsibility Pattern) 是将链中每一个节点看作是一个对象，每个节点处理的清求均不同，且内部自动维护—个下—节点对象。当—个清求从链式的首端发出时，会沿看链的路径依次传递给每—个节点对象，直至有对象处理这个清求为止。属千行为型模式。原文：Avoid coupling the sender of a request to its receiver by giving more than one object a chance to hand I e the request. Chain the receiving objects and pass the request along the chain until an object handles it.解释：使多个对象都有机会处理请求，从而避免了请求的发送者和接收者之间的耦合关系。将这些对象连成一条链，并沿着这条链传递该请求，直到有一个对象处理它为止。17.1.责任链楼式的应用场景在日常生活中责任链梩式还是比较常见的，我们平时工作处理一些事务，往往是各部门协同合作的完成莘—个任务。而每个部门都有各自的职责，因此，很多时候事谓完成—半，便会转交给下—个部门，直到所有部门都过一渔之后事谓才能完成。还有我们平时俗话说的过五关、斩六将其实也是一种责任链。[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-rbOpRRVv-1584275821165)(https://miion.coding.net/p/miion/d/image-hosting/git/raw/master/image-20200315163552414.png)]责任链模式主要是解耦了请求与处理,客户只需将清求发送到链上即可，无需关心请求的具体内容和处理细节，请求会自动进行传递直至有节点对象进行处理。适用于以下应用场景 ：1 、多个对象可以处理同一清求，但具体由哪个对象处理则在运行时动态决定；2、在不明确指定接收者的情况下，向多个对象中的—个提交—个请求；3、可动态指定一组对象处理请求。首先来看下责任链模式的通用 UML 类图 ：从 UML类图中,我们可以看到,责任链模式主要包含两种角色:抽象处理者（Handler）:定义一个请求处理的方法，并维护一个下一个处理节点Handler对象的引用；具体处理者（ConcreteHandler）:对请求进行处理,如果不感兴趣，则进行转发。 责任链模式的本质是解耦请求与处理，让请求在处理链中能进行传递与被处理；理解责任链模式应当理解的是其模式（道 ）而不是其具体实现（术 ），责任链模式的独到之处是其将节点处理者组合成了链式结构，并允许节点自身决定是否进行请求处理或转发，相当于让请求流动了起来。17.2.利用责任链模式进行数据校验拦截首 先， 创建一个实体类Member :@Data public class Member { private String loginName; private String loginPass; private String roleName; public Member(String loginName, String loginPass) { this.loginName = loginName; this.loginPass = loginPass; } }然后来看一段我们经常写的代码：public class MemberService { public static void main(String[] args) { MemberService service = new MemberService(); service.login("tom", "666"); } public void login(String loginName, String loginPass) { if (StringUtils.isEmpty(loginName) || StringUtils.isEmpty(loginPass)) { System.out.println("用户名和密码为空"); return; } System.out.println("用户名和密码不为空，可以往下执行"); Member member = checkExists(loginName, loginPass); if (null == member) { System.out.println("用户不存在"); return; } System.out.println("登录成功！"); if (!"管理员".equals(member.getRoleName())) { System.out.println("您不是管理员，没有操作权限"); return; } System.out.println("允许操作"); } private Member checkExists(String loginName, String loginPass) { Member member = new Member(loginName, loginPass); member.setRoleName("管理员"); return member; } }请问各位小伙伴，你们是不是经常这么干？上面的代码中，主要功能是做了登录前的数据验证，然后， 判断逻辑是有先后顺序的。首先做非空判断，然后检查账号是否有效，最终获得用户角色。然后根据用户角色所拥有的权限再匹配是否有操作权限。那么这样的检验性代码一般都是必不可少的， 但是写在具体的业务代码又显得代码非常臃肿，因此我们可以用责任链模式， 将这些检查步骤串联起来，而且不影响代码美观。可以使得我们在编码时可以更加专注于某一个具体的业务逻辑处理。下面我们用责任链模式来优化一下代码，首先创建一个Handler类 ：public abstract class Handler { protected Handler next; public void next(Handler next){ this.next = next;} public abstract void doHandler(Member member); }我们分别创建非空校验ValidateHandler类、登录校验LoginHandler类和权限校验AuthHandler类 ，来看代码ValidateHandler类 ：public class ValidateHandler extends Handler { public void doHandler(Member member) { if (StringUtils.isEmpty(member.getLoginName()) || StringUtils.isEmpty(member.getLoginPass())) { System.out.println("用户名和密码为空"); return; } System.out.println("用户名和密码不为空，可以往下执行"); next.doHandler(member); } }LoginHandler 类:public class LoginHandler extends Handler { public void doHandler(Member member) { System.out.println("登录成功！"); member.setRoleName("管理员"); next.doHandler(member); } }AuthHandler 类:public class AuthHandler extends Handler { public void doHandler(Member member) { if (!"管理员".equals(member.getRoleName())) { System.out.println("您不是管理员，没有操作权限"); return; } System.out.println("允许操作"); } }接下来,修 改Memberservice中的代码,其实我们只需要将前面定义好的几个Handler根据业务需求串联起来，形成一条链即可public class MemberService { public void login(String loginName, String loginPass) { Handler validateHandler = new ValidateHandler(); Handler loginHandler = new LoginHandler(); Handler authHandler = new AuthHandler(); validateHandler.next(loginHandler); loginHandler.next(authHandler); validateHandler.doHandler(new Member(loginName, loginPass)); } }来看客户端调用代码:public class Test { public static void main(String[] args) { MemberService memberService = new MemberService(); memberService.login("tom","666"); } }其运行结果如下:其实我们平时使用的很多权限校验框架都是运用这样一个原理，将各个维度的权限处理解耦之后再串联起来，各自只处理各自相关的职责。如果职责与自己不相关则抛给链上的下一个Handler, 俗称踢皮球。17.3.责任链模式和建造者模式结合使用因为责任链模式具备链式结构，而上面代码中，我们看到，负责组装链式结构的角色是MemberService ,当链式结构较长时,MemberService的工作会非常繁琐,并且MemberService代码相对臃肿，且后续更改处理者或消息类型时，都必须在MemberService中进行修改,不符合开闭原 则。产生这些问题的原因就是因为链式结构的组装过于复杂,而对于复杂结构的创建，很自然我们就会想到建造者模式,使用建造者模式，我们完全可以MemberService指定的处理节点对象进行自动链式组装，客户只需指定处理节点对象，其他任何事情都无需关心，并且客户指定的处理节点对象顺序不同 ，构造出来的链式结构也随之不同。我们来改造一下，修改Handler的代码：public abstract class Handler<T> { protected Handler next; public void next(Handler next){ this.next = next;} public abstract void doHandler(Member member); public static class Builder<T>{ private Handler<T> head; private Handler<T> tail; public Builder<T> addHandler(Handler handler){ // do { if (this.head == null) { this.head = this.tail = handler; return this; } this.tail.next(handler); this.tail = handler; // }while (false);//真正框架中，如果是双向链表，会判断是否已经到了尾部 return this; } public Handler<T> build(){ return this.head; } } }然 后 ，修改MemberService的代码：public class MemberService { public void login(String loginName,String loginPass){ Handler.Builder builder = new Handler.Builder(); builder.addHandler(new ValidateHandler()) .addHandler(new LoginHandler()) .addHandler(new AuthHandler()); builder.build().doHandler(new Member(loginName,loginPass)); //用过Netty的人，肯定见过 } }因为建造者模式要构建的是节点处理者，因此我们把Builder作为Handler的静态内部类，并且因 为客户端无需进行链式组装，因此我们还可以把链式组装方法next。方法设置为private，使 Handler更加高内聚，代码如下：public abstract class Handler<T> { protected Handler chain; private void next(Handler handler) { this.chain = handler; } }通过这个案例，小伙伴们应该已经感受到责任链和建造者结合的精 ITo17.4.责任链模式在源码中的体现首先我们来看责任链模式在JDK中的应用，来看一个J2EE标准中非常常见的Filter类:public interface Filter { public void init(FilterConfig filterConfig) throws ServletException; public void doFilter(ServletRequest request, ServletResponse response, FilterChain chain) throws IOException, ServletException; public void destroy(); }这个Filter接口的定义非常简单，相当于责任链模型中的Handler抽象角色，那么它是如何形成一 条责任链的呢？我来看另外一个类，其实在doFilte()方法的最后一个参数我们已经看到其类型是FilterChain类 ，来看它的源码：public interface FilterChain { public void doFilter(ServletRequest request, ServletResponse response) throws IOException, ServletException; }FilterChain类中也只定义了一个doFilter()方法,那么它们是怎么串联成一个责任链的呢？实际上 J2EE只是定义了一个规范，具体处理逻辑是由使用者自己来实现。我们来看一个Spring的实现MockFilterChain类:public class MockFilterChain implements FilterChain { @Nullable private ServletRequest request; @Nullable private ServletResponse response; private final List<Filter> filters; @Nullable private Iterator<Filter> iterator; public MockFilterChain() { this.filters = Collections.emptyList(); } public MockFilterChain(Servlet servlet) { this.filters = initFilterList(servlet); } public MockFilterChain(Servlet servlet, Filter... filters) { Assert.notNull(filters, "filters cannot be null"); Assert.noNullElements(filters, "filters cannot contain null values"); this.filters = initFilterList(servlet, filters); } private static List<Filter> initFilterList(Servlet servlet, Filter... filters) { Filter[] allFilters = ObjectUtils.addObjectToArray(filters, new ServletFilterProxy(servlet)); return Arrays.asList(allFilters); } @Nullable public ServletRequest getRequest() { return this.request; } @Nullable public ServletResponse getResponse() { return this.response; } @Override public void doFilter(ServletRequest request, ServletResponse response) throws IOException, ServletException { Assert.notNull(request, "Request must not be null"); Assert.notNull(response, "Response must not be null"); Assert.state(this.request == null, "This FilterChain has already been called!"); if (this.iterator == null) { this.iterator = this.filters.iterator(); } if (this.iterator.hasNext()) { Filter nextFilter = this.iterator.next(); nextFilter.doFilter(request, response, this); } this.request = request; this.response = response; } public void reset() { this.request = null; this.response = null; this.iterator = null; } private static class ServletFilterProxy implements Filter { private final Servlet delegateServlet; private ServletFilterProxy(Servlet servlet) { Assert.notNull(servlet, "servlet cannot be null"); this.delegateServlet = servlet; } @Override public void doFilter(ServletRequest request, ServletResponse response, FilterChain chain) throws IOException, ServletException { this.delegateServlet.service(request, response); } @Override public void init(FilterConfig filterConfig) throws ServletException { } @Override public void destroy() { } @Override public String toString() { return this.delegateServlet.toString(); } } }它把链条中的所有Filter放到List中 ，然后在调用doFilter。方法时循环迭代List , 也就是说List中的Filter会顺序执行。再来看一个在Netty中非常经典的串行化处理Pipeline就采用了责任链设计模式。它底层采用双向 链表的数据结构，将链上的各个处理器串联起来。客户端每一个请求的到来,Netty都认为Pipeline中 的所有的处理器都有机会处理它。因此，对于入栈的请求全部从头节点开始往后传播，一直传播到尾节点才会把消息释放掉。来看一个Netty的责任处理器接口 ChannelHandler:public interface ChannelHandler { // 当 handler被添加到真实的上下文中，并且准备处理事件时被调用 // handler被添加进去的回调 void handlerAdded(ChannelHandlerContext var1) throws Exception; // 是 handler被移出的后的回调 void handlerRemoved(ChannelHandlerContext var1) throws Exception; /** @deprecated */ @Deprecated void exceptionCaught(ChannelHandlerContext var1, Throwable var2) throws Exception; @Inherited @Documented @Target({ElementType.TYPE}) @Retention(RetentionPolicy.RUNTIME) public @interface Sharable { } }Netty对责任处理接口做了更细粒度的划分，处理器被分成了两种，一种是入栈处理器ChannellnboundHandler, 另一种是出栈处理器ChannelOutboundHandler, 这两个接口都继承自ChannelHandler.而所有的处理器最终都在添加在Pipeline上。所 以 ，添加删除责任处理器的接口的行为在Netty的 Channelpipeline中的进行了规定：public interface ChannelPipeline extends ChannelInboundInvoker,ChannelOutboundInvoker, Iterable<Entry<String, ChannelHandler>> { ChannelPipeline addFirst(String name, ChannelHandler handler); ChannelPipeline addFirst(EventExecutorGroup group, String name, ChannelHandler handler); ChannelPipeline addLast(String name, ChannelHandler handler); ChannelPipeline addLast(EventExecutorGroup group, String name, ChannelHandler handler); ChannelPipeline addBefore(String baseName, String name, ChannelHandler handler); ... }在默认是实现类中将所有的Handler都串成了一个链表:public class DefaultChannelPipeline implements ChannelPipeline { static final InternalLogger logger = InternalLoggerFactory.getInstance(DefaultChannelPipeline.class); final AbstractChannelHandlerContext head; final AbstractChannelHandlerContext tail; ... }在 Pipeline中的任意一个节点，只要我们不手动的往下传播下去,这个事件就会终止传播在当前节 点。对于入栈数据，默认会传递到尾节点进行回收。如果我们不进行下一步传播，事件就会终止在当前节点。对于出栈数据把数据写会客户端也意味看事件的终止。当然在很多安全框架中也会大量使用责任链模式,比如Spring Security. Apache Shiro都会用到设计模式中的责任链模式,感兴趣的小伙伴可以尝试自己去研究一下。大部分框架中无论怎么实现，所有的实现都是大同小异的。其实如果我们是站在设计者这个角度看源码的话，对我们学习源码和编码内功是非常非常有益处的，因为这样，我们可以站在更高的角度来学习优秀的思想，而不是钻到某一个代码细节里边。我们需要对所有的设计必须有一个宏观概念，这样学习起来才更加轻松。17.5.责任链模式的优缺点优点：​ 1、将请求与处理解耦；​ 2、请求处理者(节点对象)只需关注自己感兴趣的请求进行处理即可，对于不感兴趣的请求，直接转发给下一级节点对象;​ 3、 具备链式传递处理请求功能，请求发送者无需知晓链路结构，只需等待请求处理结果；​ 4、 链路结构灵活，可以通过改变链路结构动态地新增或删减责任；5、 易于扩展新的请求处理类（节点），符合开闭原则。缺点：​ 1、 责任链太长或者处理时间过长，会影响整体性能​ 2、 如果节点对象存在循环引用时，会造成死循环，导致系统崩溃；17.6.作业1、利用策略模式重构一段业务代码。使用策略模式实现一个计算器。步骤 1创建一个接口。public interface Strategy { public int doOperation(int num1, int num2); }步骤 2创建实现接口的实体类。// 加 public class OperationAdd implements Strategy{ @Override public int doOperation(int num1, int num2) { return num1 + num2; } } // 减 public class OperationSubstract implements Strategy{ @Override public int doOperation(int num1, int num2) { return num1 - num2; } } // 乘 public class OperationMultiply implements Strategy{ @Override public int doOperation(int num1, int num2) { return num1 * num2; } }步骤 3创建 Context 类。public class Context { private Strategy strategy; public Context(Strategy strategy){ this.strategy = strategy; } public int executeStrategy(int num1, int num2){ return strategy.doOperation(num1, num2); } }步骤 4使用 Context 来查看当它改变策略 Strategy 时的行为变化。public class StrategyPatternDemo { public static void main(String[] args) { Context context = new Context(new OperationAdd()); System.out.println("10 + 5 = " + context.executeStrategy(10, 5)); context = new Context(new OperationSubstract()); System.out.println("10 - 5 = " + context.executeStrategy(10, 5)); context = new Context(new OperationMultiply()); System.out.println("10 * 5 = " + context.executeStrategy(10, 5)); } }步骤 5执行程序，输出结果：10 + 5 = 15 10 - 5 = 5 10 * 5 = 502、请描述出责任链模式和建造者模式结合应用的精髓。责任链模式通过于建造者模式结合，可以有效控制链表顺序。

快照策略(SnapshotStrategy)Flink的检查点机制是建立在分布式一致快照之上的，从而实现数据处理的exactly-once处理语义。无论是Keyed state(HeapKeyStateBackend、RocksDBKeyedStateBackend)还是Operator state(DefaultOperatorStateBackend)都会接收快照执行请求(snapshot方法)，而具体的快照操作都交由具体的snapshot策略完成。下面是Flink快照策略UML，可以看到Keyed state中的HeapSnapshotStrategy和RocksDBSnapshotStrategyBase分别对应堆内存和RocksDB(RocksDB又细分为全量快照和增量快照)存储后端的快照执行策略，而DefaultOperatorStateBackendSnapshotStrategy对应着Operator state存储后端快照执行策略。除了Keyed state和Operator state之外，因为savepoint本质也是snapshot的特殊实现，所以对应的savepoint执行策略SavepointSnapshotStrategy也实现了SnapshotStrategy接口。下面是SnapshotStrategy接口定义，其中定义了执行快照的所需步骤：同步执行部分，用于生成执行快照所需的资源，为下一步写入快照数据做好资源准备。异步执行部分，将快照数据写入到提供的CheckpointStreamFactory中。public interface SnapshotStrategy<S extends StateObject, SR extends SnapshotResources> { //同步执行生成快照的部分，可以理解为为执行快照准备必要的资源。 SR syncPrepareResources(long checkpointId) throws Exception; //异步执行快照写入部分，快照数据写入到CheckpointFactory SnapshotResultSupplier<S> asyncSnapshot( SR syncPartResource, long checkpointId, long timestamp, @Nonnull CheckpointStreamFactory streamFactory, @Nonnull CheckpointOptions checkpointOptions); //用于执行异步快照部分的Supplier @FunctionalInterface interface SnapshotResultSupplier<S extends StateObject> { //Performs the asynchronous part of a checkpoint and returns the snapshot result. SnapshotResult<S> get(CloseableRegistry snapshotCloseableRegistry) throws Exception; } }下面是SnapshotResources所对应的UML图：全量快照FullSnapshotResources下分别对应着堆内存快照资源HeapSnapshotResources以及RocksDB全量快照资源实现类RocksDBFullSnapshotResourcesRocksDB增量快照资源实现类IncrementalRocksDBSnapshotResoruces。Operator state快照资源实现类DefaultOperatorStateBackendSnapshotResources。SnapshotResources接口定义如下，只有一个release方法定义，用于在异步Snapshot执行完成后清空资源。@Internal public interface SnapshotResources { /** Cleans up the resources after the asynchronous part is done. */ void release(); }关于具体资源实现类我们在对应的快照策略中来查看。堆内存快照策略(HeapSnasphotStrategy)在看堆内存快照策略之前，我们先看下堆内存执行快照所对应的资源类HeapSnapshotResources。通过上面的UML我们可以看到堆内存快照和RocksDB全量快照都实现了FullSnapshotResources，这也说明了堆内存存储后端不存在增量快照的实现。FullSnapshotResources定义了与具体存储后端无关的全量执行全量快照资源，它们都是通过FullSnapshotAsyncWriter来写快照数据。FullSnapshotResources接口定义如下，其中泛型K代表了具体存储key的数据类型。public interface FullSnapshotResources<K> extends SnapshotResources { //返回此状态快照的元数据列表，StateMetaInfoSnapshot记录每个状态对应快照元数据信息，比如state name、 backend 类型、序列化器等。 List<StateMetaInfoSnapshot> getMetaInfoSnapshots(); //创建用于遍历当前快照的迭代器 KeyValueStateIterator createKVStateIterator() throws IOException; //当前快照对应的KeyGroupRange KeyGroupRange getKeyGroupRange(); /** Returns key {@link TypeSerializer}. */ TypeSerializer<K> getKeySerializer(); /** Returns the {@link StreamCompressionDecorator} that should be used for writing. */ StreamCompressionDecorator getStreamCompressionDecorator(); } 下面我们看下HeapSnapshotStrategy中的两个核心方法syncPrepareResources和asyncSnapshot。class HeapSnapshotStrategy<K> implements SnapshotStrategy<KeyedStateHandle, HeapSnapshotResources<K>> { ... //准备snapshot资源HeapSnapshotResources @Override public HeapSnapshotResources<K> syncPrepareResources(long checkpointId) { return HeapSnapshotResources.create( registeredKVStates, registeredPQStates, keyGroupCompressionDecorator, keyGroupRange, getKeySerializer(), totalKeyGroups); } @Override public SnapshotResultSupplier<KeyedStateHandle> asyncSnapshot( HeapSnapshotResources<K> syncPartResource, long checkpointId, long timestamp, @Nonnull CheckpointStreamFactory streamFactory, @Nonnull CheckpointOptions checkpointOptions) { ...... //SupplierWithException是Java Supplier可能抛出异常的函数接口，第一个泛型参数是supplier执行返回类型，第二个参数为Supplier中函数抛出的异常 final SupplierWithException<CheckpointStreamWithResultProvider, Exception> checkpointStreamSupplier = localRecoveryConfig.isLocalRecoveryEnabled() //是否使用本地恢复 && !checkpointOptions.getCheckpointType().isSavepoint() ? () -> createDuplicatingStream( //本地恢复并且当前不是savepoint，创建复制流 checkpointId, CheckpointedStateScope.EXCLUSIVE, streamFactory, localRecoveryConfig .getLocalStateDirectoryProvider()) : () -> createSimpleStream(//非本地恢复，或者是savepoint，创建简单流 CheckpointedStateScope.EXCLUSIVE, streamFactory); return (snapshotCloseableRegistry) -> { ...... //输出数据流 final CheckpointStreamFactory.CheckpointStateOutputStream localStream = streamWithResultProvider.getCheckpointOutputStream(); ////使用KeyedBackendSerializationProxy写cp数据 final DataOutputViewStreamWrapper outView = new DataOutputViewStreamWrapper(localStream); serializationProxy.write(outView); ...... }; } }上面asyncSnapshot方法通过CheckpointStreamWithResultProvider来创建快照输出流。该类核心就是封装了获取输出流，如果没有配置本地状态恢复，只会创建一个输出流来讲snapshot数据写入到job所配置的Checkpoint存储。如果配置了本地恢复，就需要将状态数据写本地了(本地数据恢复)，所以对于这种情况会获取两个输出流，一个用于写配置的Checkpoint存储，一个用于写本地。public interface CheckpointStreamWithResultProvider extends Closeable { //关闭输出流，并返回带有流句柄的快照结果 @Nonnull SnapshotResult<StreamStateHandle> closeAndFinalizeCheckpointStreamResult() throws IOException; //返回snapshot输出流 @Nonnull CheckpointStreamFactory.CheckpointStateOutputStream getCheckpointOutputStream(); @Override default void close() throws IOException { getCheckpointOutputStream().close(); } ... }而CheckpointStreamWithResultProvider的两个内部实现类也就分别对应了创建simple流(PrimaryStreamOnly，只会创建一个输出流， 这个流是我们配置checkpoint存储的写入地方，可能是远端HDFS、JobManager等)，和创建duplicating流(PrimaryAndSecondaryStream，两个输出流，第一个流和PrimaryStreamOnly一样；第二个输出流用于写入到本地、TaskManager等，用于本地恢复)。创建simple stream，下面可以看到只会创建一个primary stream。static CheckpointStreamWithResultProvider createSimpleStream( @Nonnull CheckpointedStateScope checkpointedStateScope, @Nonnull CheckpointStreamFactory primaryStreamFactory) throws IOException { //创建主输出流 CheckpointStreamFactory.CheckpointStateOutputStream primaryOut = primaryStreamFactory.createCheckpointStateOutputStream(checkpointedStateScope); return new CheckpointStreamWithResultProvider.PrimaryStreamOnly(primaryOut); }创建duplicating stream，可以看到除了一个primary stream外，还会创建写文件的second stream。@Nonnull static CheckpointStreamWithResultProvider createDuplicatingStream( @Nonnegative long checkpointId, @Nonnull CheckpointedStateScope checkpointedStateScope, @Nonnull CheckpointStreamFactory primaryStreamFactory, @Nonnull LocalRecoveryDirectoryProvider secondaryStreamDirProvider) throws IOException { CheckpointStreamFactory.CheckpointStateOutputStream primaryOut = primaryStreamFactory.createCheckpointStateOutputStream(checkpointedStateScope); try { //cp数据写出路径 File outFile = new File( secondaryStreamDirProvider.subtaskSpecificCheckpointDirectory( checkpointId), String.valueOf(UUID.randomUUID())); Path outPath = new Path(outFile.toURI()); //构建写入文件的输出流 CheckpointStreamFactory.CheckpointStateOutputStream secondaryOut = new FileBasedStateOutputStream(outPath.getFileSystem(), outPath); return new CheckpointStreamWithResultProvider.PrimaryAndSecondaryStream( primaryOut, secondaryOut); } catch (IOException secondaryEx) { LOG.warn( "Exception when opening secondary/local checkpoint output stream. " + "Continue only with the primary stream.", secondaryEx); } return new CheckpointStreamWithResultProvider.PrimaryStreamOnly(primaryOut); }上面CheckpointStreamFactory创建输出流，该输出流用于将Checkpoint数据写入到外部，比如通过FsCheckpoihntStreamFactory将检查点数据写到外部文件系统。public interface CheckpointStreamFactory { //创建一个新的状态输出流，CheckpointStateOutputStream为当前CheckpointStreamFactory内部静态抽象类 CheckpointStateOutputStream createCheckpointStateOutputStream(CheckpointedStateScope scope) throws IOException; //CheckpointStateOutputStream基类，相关实现都在CheckpointStreamFactory的子类 abstract class CheckpointStateOutputStream extends FSDataOutputStream { //关闭数据流并获取句柄 @Nullable public abstract StreamStateHandle closeAndGetHandle() throws IOException; //关闭数据流 @Override public abstract void close() throws IOException; } }RocksDB快照存储策略上面的UML我们可以知道RocksDB快照存储策略主要对应三个核心类，抽象类RocksDBSnapshotStrategyBase、全量快照策略RocksDBFullSnapshotStrategy和增量快照策略RocksDBIncrementalSnapshotStrategy。RocksDBSnapshotStrategyBase定义了一些RocksDB、state相关的成员变量，具体实现都在相关子类中。全量快照全量快照RocksDBFullSnapshotStrategy用于创建RocksDBKeyedStateBackend的全量快照，每次Checkpoint会将全量状态数据同步到远端(JobManager或HDFS)。下面我们同样看下核心方法：asyncPrepareResources和asyncSnapshot。public class RocksFullSnapshotStrategy<K> extends RocksDBSnapshotStrategyBase<K, FullSnapshotResources<K>> { ...... @Override public FullSnapshotResources<K> syncPrepareResources(long checkpointId) throws Exception { //构建RocksDB全量快照资源类，RocksDBFullSnapshotResources和HeapFullSnapshotResources相比，包含了 //RocksDB 实例和快照Snapshot return RocksDBFullSnapshotResources.create( kvStateInformation, registeredPQStates, db, rocksDBResourceGuard, keyGroupRange, keySerializer, keyGroupPrefixBytes, keyGroupCompressionDecorator); } @Override public SnapshotResultSupplier<KeyedStateHandle> asyncSnapshot( FullSnapshotResources<K> fullRocksDBSnapshotResources, long checkpointId, long timestamp, @Nonnull CheckpointStreamFactory checkpointStreamFactory, @Nonnull CheckpointOptions checkpointOptions) { if (fullRocksDBSnapshotResources.getMetaInfoSnapshots().isEmpty()) { if (LOG.isDebugEnabled()) { LOG.debug( "Asynchronous RocksDB snapshot performed on empty keyed state at {}. Returning null.", timestamp); } return registry -> SnapshotResult.empty(); } //createCheckpointStreamSupplier和Heap中一样，根据是否启动本地恢复，创建Duplicating和simple stream final SupplierWithException<CheckpointStreamWithResultProvider, Exception> checkpointStreamSupplier = createCheckpointStreamSupplier( checkpointId, checkpointStreamFactory, checkpointOptions); //创建全量异步Writer return new FullSnapshotAsyncWriter<>( checkpointOptions.getCheckpointType(), checkpointStreamSupplier, fullRocksDBSnapshotResources); } ...... }FullSnapshotAsyncWriter也是一个Supplier，用于异步写全量快照数据到给定的输出流中。public class FullSnapshotAsyncWriter<K> implements SnapshotStrategy.SnapshotResultSupplier<KeyedStateHandle> { @Override public SnapshotResult<KeyedStateHandle> get(CloseableRegistry snapshotCloseableRegistry) throws Exception { ...... //获取输出流 final CheckpointStreamWithResultProvider checkpointStreamWithResultProvider = checkpointStreamSupplier.get(); snapshotCloseableRegistry.registerCloseable(checkpointStreamWithResultProvider); //写快照数据到输出流中 writeSnapshotToOutputStream(checkpointStreamWithResultProvider, keyGroupRangeOffsets); ...... } private void writeSnapshotToOutputStream( @Nonnull CheckpointStreamWithResultProvider checkpointStreamWithResultProvider, @Nonnull KeyGroupRangeOffsets keyGroupRangeOffsets) throws IOException, InterruptedException { //通过输出视图将快照数据写入到指定输出流中，注意 checkpointStreamWithResultProvider可能写两份数据 final DataOutputView outputView = new DataOutputViewStreamWrapper( checkpointStreamWithResultProvider.getCheckpointOutputStream()); //写元数据 writeKVStateMetaData(outputView); //为每个state实例写状态数据 try (KeyValueStateIterator kvStateIterator = snapshotResources.createKVStateIterator()) { writeKVStateData( kvStateIterator, checkpointStreamWithResultProvider, keyGroupRangeOffsets); } } }下面我们看下最关键的writeKVStateData，到底是怎么将全量数据写到外部的。我们抛开繁杂的细节，就看这里怎么写的。可以看到实际就是迭代KeyValueStateIterator。private void writeKVStateData( final KeyValueStateIterator mergeIterator, final CheckpointStreamWithResultProvider checkpointStreamWithResultProvider, final KeyGroupRangeOffsets keyGroupRangeOffsets) throws IOException, InterruptedException { ...... try { ...... //就是遍历KeyValueStateIterator迭代器 // main loop: write k/v pairs ordered by (key-group, kv-state), thereby tracking // key-group offsets. while (mergeIterator.isValid()) { ...... writeKeyValuePair(previousKey, previousValue, kgOutView); ...... // request next k/v pair previousKey = mergeIterator.key(); previousValue = mergeIterator.value(); mergeIterator.next(); } ...... } finally { // this will just close the outer stream IOUtils.closeQuietly(kgOutStream); } }KeyValueStateIterator就是记录了当前快照的所有key-value实体，RocksDB和Heap分别有各自的迭代器实现。我们看下RocksStatesPerKeyGroupMergeIterator是如何创建的。我们在上面看FullSnapshotResources接口时看到了抽象方法createKVStateIterator定义，该方法就是专门用于创建迭代器的。HeapSnapshotResources和RocksDBFullSnapshotResources分别实现了该方法来创建Heap和RocksDB迭代器。下面是RocksDBFullSnapshotResources.createKVStateIterator实现。@Override public KeyValueStateIterator createKVStateIterator() throws IOException { ...... try { //创建RocksDB ReadOptions，设置读取上面的RocksDB snapshot，该snapshot是在Checkpoint同步阶段生成的 ReadOptions readOptions = new ReadOptions(); closeableRegistry.registerCloseable(readOptions::close); readOptions.setSnapshot(snapshot); //RocksDBIteratorWrapper是对RocksDBIterator的一层包装 List<Tuple2<RocksIteratorWrapper, Integer>> kvStateIterators = createKVStateIterators(closeableRegistry, readOptions); ....... //RocksStatesPerKeyGroupMergeIterator实际是将多个state实例(ColumnFamily)的迭代器包成一个迭代器 return new RocksStatesPerKeyGroupMergeIterator( closeableRegistry, kvStateIterators, heapPriorityQueueIterators, keyGroupPrefixBytes); } catch (Throwable t) { IOUtils.closeQuietly(closeableRegistry); throw new IOException("Error creating merge iterator", t); } } private List<Tuple2<RocksIteratorWrapper, Integer>> createKVStateIterators( CloseableRegistry closeableRegistry, ReadOptions readOptions) throws IOException { final List<Tuple2<RocksIteratorWrapper, Integer>> kvStateIterators = new ArrayList<>(metaData.size()); int kvStateId = 0; //每个state，也就是每个RocksDB的ColumnFamily都会创建一个迭代器 for (MetaData metaDataEntry : metaData) { RocksIteratorWrapper rocksIteratorWrapper = createRocksIteratorWrapper( db, metaDataEntry.rocksDbKvStateInfo.columnFamilyHandle, metaDataEntry.stateSnapshotTransformer, readOptions); kvStateIterators.add(Tuple2.of(rocksIteratorWrapper, kvStateId)); closeableRegistry.registerCloseable(rocksIteratorWrapper); ++kvStateId; } return kvStateIterators; } private static RocksIteratorWrapper createRocksIteratorWrapper( RocksDB db, ColumnFamilyHandle columnFamilyHandle, StateSnapshotTransformer<byte[]> stateSnapshotTransformer, ReadOptions readOptions) { //创建RocksDB Iterator，被包在了Flink定义的RocksDBIteratorWrapper中 RocksIterator rocksIterator = db.newIterator(columnFamilyHandle, readOptions); return stateSnapshotTransformer == null ? new RocksIteratorWrapper(rocksIterator) : new RocksTransformingIteratorWrapper(rocksIterator, stateSnapshotTransformer); }上面代码可以看到这里的迭代器其实本质还是RocksDB自己的迭代器(指定了读取的snapshot)，Flink将其包在了RocksDBIteratorWrapper中(为什么需要包一层可以查看RocksDB自身官网Iterator异常处理)。因为可能有多个state实例，每个实例都有自己的一个迭代器，最后Flink将这些迭代器封装到一个迭代器中，即RocksStatetsPerKeyGroupMergeIterator。增量快照RocksIncrementalSnapshotStrategy是RocksDBKeyedStateBackend增量快照策略，它是基于RocksDB的native Checkpoint来实现增量快照的。我们在看RocksIncrementalSnapshotStrategy的syncPrepareResources和asyncSnapshot前，先看下RocksDB增量快照会用到的一些关键成员变量。//RocksDB增量快照资源信息为内部类IncrementalRocksDBSnapshotResources public class RocksIncrementalSnapshotStrategy<K> extends RocksDBSnapshotStrategyBase< K, RocksIncrementalSnapshotStrategy.IncrementalRocksDBSnapshotResources> { //RocksDB实例目录 @Nonnull private final File instanceBasePath; /** The state handle ids of all sst files materialized in snapshots for previous checkpoints. */ @Nonnull private final UUID backendUID; //记录了checkpoint id和当前checkpoint sst文件映射关系 @Nonnull private final SortedMap<Long, Set<StateHandleID>> materializedSstFiles; //最后一次完成的Checkpoint ID private long lastCompletedCheckpointId; //用于上传快照文件(RocksDB checkpoint生成的sst文件等) private final RocksDBStateUploader stateUploader; ... }下面我们再看下同步资源准备阶段，主要做了两件事:获取最近一次Checkpoint生成的sst文件，也就是通过materializedSstFiles获取。用于增量文件对比。创建RocksDB Checkpoint。@Override public IncrementalRocksDBSnapshotResources syncPrepareResources(long checkpointId) throws Exception { //目录准备，如果开启本地恢复，则创建永久目录，否则创建临时目录 final SnapshotDirectory snapshotDirectory = prepareLocalSnapshotDirectory(checkpointId); LOG.trace("Local RocksDB checkpoint goes to backup path {}.", snapshotDirectory); final List<StateMetaInfoSnapshot> stateMetaInfoSnapshots = new ArrayList<>(kvStateInformation.size()); //最近一次完成的Checkpoint 所生成的sst文件，用于增量对比 final Set<StateHandleID> baseSstFiles = snapshotMetaData(checkpointId, stateMetaInfoSnapshots); //创建RocksDB 检查点 takeDBNativeCheckpoint(snapshotDirectory); return new IncrementalRocksDBSnapshotResources( snapshotDirectory, baseSstFiles, stateMetaInfoSnapshots); }takeDBNativeCheckpoint就是同步创建RocksDB的Checkpoint，Checkpoint数据会在指定目录生成(sst文件、misc文件)。private void takeDBNativeCheckpoint(@Nonnull SnapshotDirectory outputDirectory) throws Exception { try (ResourceGuard.Lease ignored = rocksDBResourceGuard.acquireResource(); Checkpoint checkpoint = Checkpoint.create(db)) { checkpoint.createCheckpoint(outputDirectory.getDirectory().toString()); } catch (Exception ex) { ...... } } asyncSnapshot内部很简单，主要创建RocksDBIncrementalSnapshotOperation Supplier来创建增量快照。@Override public SnapshotResultSupplier<KeyedStateHandle> asyncSnapshot( IncrementalRocksDBSnapshotResources snapshotResources, long checkpointId, long timestamp, @Nonnull CheckpointStreamFactory checkpointStreamFactory, @Nonnull CheckpointOptions checkpointOptions) { ... return new RocksDBIncrementalSnapshotOperation( checkpointId, checkpointStreamFactory, snapshotResources.snapshotDirectory, //RocksDB Checkpoint生成目录 snapshotResources.baseSstFiles, //上次Cp完成的sst文件 snapshotResources.stateMetaInfoSnapshots); } 下面我们看下增量快照实现的核心RocksDBIncrementalSnapshotOperation。private final class RocksDBIncrementalSnapshotOperation implements SnapshotResultSupplier<KeyedStateHandle> { ... @Override public SnapshotResult<KeyedStateHandle> get(CloseableRegistry snapshotCloseableRegistry) throws Exception { ... // 当前RocksDB checkpoint生成的sst文件 final Map<StateHandleID, StreamStateHandle> sstFiles = new HashMap<>(); // 当前RocksDB Checkpoint的misc files(元数据文件) final Map<StateHandleID, StreamStateHandle> miscFiles = new HashMap<>(); ...... //上传增量sst文件和misc 文件，uploadSstFiles方法内部获取遍历RocksDB Checkpoint目录比较新增sst文件 uploadSstFiles(sstFiles, miscFiles, snapshotCloseableRegistry); //塞入当前Checkpoint对应sst文件 synchronized (materializedSstFiles) { materializedSstFiles.put(checkpointId, sstFiles.keySet()); } ...... } }我们再看下上面的uploadSstFiles方法实现： private void uploadSstFiles( @Nonnull Map<StateHandleID, StreamStateHandle> sstFiles, @Nonnull Map<StateHandleID, StreamStateHandle> miscFiles, @Nonnull CloseableRegistry snapshotCloseableRegistry) throws Exception { //增量sst本地文件路径 Map<StateHandleID, Path> sstFilePaths = new HashMap<>(); //misc文件路径 Map<StateHandleID, Path> miscFilePaths = new HashMap<>(); //当前RocksDB Checkpoint目录 Path[] files = localBackupDirectory.listDirectory(); if (files != null) { //查找增量文件 createUploadFilePaths(files, sstFiles, sstFilePaths, miscFilePaths); //使用stateUploader上传增量sst文件 sstFiles.putAll( stateUploader.uploadFilesToCheckpointFs( sstFilePaths, checkpointStreamFactory, snapshotCloseableRegistry)); //上传misc文件 miscFiles.putAll( stateUploader.uploadFilesToCheckpointFs( miscFilePaths, checkpointStreamFactory, snapshotCloseableRegistry)); } }上面createUploadFilesPaths方法用于对比查找增量sst文件，并生成要被上传的sst文件和misc文件。private void createUploadFilePaths( Path[] files, Map<StateHandleID, StreamStateHandle> sstFiles, Map<StateHandleID, Path> sstFilePaths, Map<StateHandleID, Path> miscFilePaths) { for (Path filePath : files) { final String fileName = filePath.getFileName().toString(); //文件句柄 final StateHandleID stateHandleID = new StateHandleID(fileName); //sst文件和最后一次Cp sst文件对比，查找增量 if (fileName.endsWith(SST_FILE_SUFFIX)) { final boolean existsAlready = baseSstFiles != null && baseSstFiles.contains(stateHandleID); if (existsAlready) { //对于之前已经存在的sst文件，只使用一个占位符说明之前上传过的，文件在共享目录 sstFiles.put(stateHandleID, new PlaceholderStreamStateHandle()); } else { //新增文件，将要被上传的 sstFilePaths.put(stateHandleID, filePath); } } else { //misc文件全部上传 miscFilePaths.put(stateHandleID, filePath); } } }可以看到增量快照的实现逻辑就是：通过RocksDB的Checkpoint生成当前快照的sst文件(由于LSM特性，sst文件是不可变的).Flink每次记录当前Checkpoint id和其快照sst文件的映射关系。上传当前Checkpoint对应的sst文件和misc文件。之后的Checkpoint中如果还有之前的sst文件，那这些文件就不需要在上传到HDFS了。可以看到Flink的增量Checkpoint就是巧妙利用了LSM 中sst文件是递增不变的特性。Operator state快照策略Operator state的快照策略只有一个，即DefaultOperatorStateBackendSnapshotStrategy，它将Operator state中的ListState和BroadcastState的快照数据写出到快照存储端。class DefaultOperatorStateBackendSnapshotStrategy implements SnapshotStrategy< OperatorStateHandle, DefaultOperatorStateBackendSnapshotStrategy .DefaultOperatorStateBackendSnapshotResources> { private final ClassLoader userClassLoader; //Operator state中只有两类state：ListState和BroadcastState private final Map<String, PartitionableListState<?>> registeredOperatorStates; private final Map<String, BackendWritableBroadcastState<?, ?>> registeredBroadcastStates; protected DefaultOperatorStateBackendSnapshotStrategy( ClassLoader userClassLoader, Map<String, PartitionableListState<?>> registeredOperatorStates, Map<String, BackendWritableBroadcastState<?, ?>> registeredBroadcastStates) { this.userClassLoader = userClassLoader; this.registeredOperatorStates = registeredOperatorStates; this.registeredBroadcastStates = registeredBroadcastStates; } ...... }在同步准备资源阶段，DefaultOperatorStateBackendSnapshotStrategy只做了一件事：深拷贝ListState和BroadcastState。深拷贝的目的就是同步创建这个时刻的快照，以保证exactly-once。@Override public DefaultOperatorStateBackendSnapshotResources syncPrepareResources(long checkpointId) { //存放拷贝后的Operator state final Map<String, PartitionableListState<?>> registeredOperatorStatesDeepCopies = new HashMap<>(registeredOperatorStates.size()); final Map<String, BackendWritableBroadcastState<?, ?>> registeredBroadcastStatesDeepCopies = new HashMap<>(registeredBroadcastStates.size()); ClassLoader snapshotClassLoader = Thread.currentThread().getContextClassLoader(); Thread.currentThread().setContextClassLoader(userClassLoader); try { //将传递ListState和BroadcastState进行深拷贝，便于后续使用 if (!registeredOperatorStates.isEmpty()) { for (Map.Entry<String, PartitionableListState<?>> entry : registeredOperatorStates.entrySet()) { PartitionableListState<?> listState = entry.getValue(); if (null != listState) { listState = listState.deepCopy(); } registeredOperatorStatesDeepCopies.put(entry.getKey(), listState); } } //拷贝broad cast state if (!registeredBroadcastStates.isEmpty()) { for (Map.Entry<String, BackendWritableBroadcastState<?, ?>> entry : registeredBroadcastStates.entrySet()) { BackendWritableBroadcastState<?, ?> broadcastState = entry.getValue(); if (null != broadcastState) { broadcastState = broadcastState.deepCopy(); } registeredBroadcastStatesDeepCopies.put(entry.getKey(), broadcastState); } } } finally { Thread.currentThread().setContextClassLoader(snapshotClassLoader); } return new DefaultOperatorStateBackendSnapshotResources( registeredOperatorStatesDeepCopies, registeredBroadcastStatesDeepCopies); }深拷贝完Operator state后，asyncSnapshot方法就开始异步写快照数据到CheckpointStreamFactory了。@Override public SnapshotResultSupplier<OperatorStateHandle> asyncSnapshot( DefaultOperatorStateBackendSnapshotResources syncPartResource, long checkpointId, long timestamp, @Nonnull CheckpointStreamFactory streamFactory, @Nonnull CheckpointOptions checkpointOptions) { ...... return (snapshotCloseableRegistry) -> { //创建输出流 CheckpointStreamFactory.CheckpointStateOutputStream localOut = streamFactory.createCheckpointStateOutputStream( CheckpointedStateScope.EXCLUSIVE); snapshotCloseableRegistry.registerCloseable(localOut); ...... //通过OperatorBackendSerializationProxy写快照数据到输出流 DataOutputView dov = new DataOutputViewStreamWrapper(localOut); OperatorBackendSerializationProxy backendSerializationProxy = new OperatorBackendSerializationProxy( operatorMetaInfoSnapshots, broadcastMetaInfoSnapshots); backendSerializationProxy.write(dov); ...... return SnapshotResult.of(retValue); } else { throw new IOException("Stream was already unregistered."); } }; }

背景很多人在学习和工作中，习惯于模仿，很难去思考主动创新。而懂得变通和创新的人非常值得大家去学习。有时候，如果大家能够抱着以终为始的思想，去作图，去设计方案，编写代码，或许能够提高进阶的速度。作图也是一样，我们不应该教条，更应该以清晰易懂为核心目标。作图案例下面举一个例子，帮助大家理解我要表达地意思。如下图为 《DDD 的最短学习路径》 GitChat 的配图看着挺棒，或许对于作者来说，可以快速分辨出不同颜色的含义。为了让大家能够理解不同颜色的含义，“贴心”地在顶部提供了图例。但对于读者来说，依然需要反复核对图例来区分不同颜色的含义。那么为什么不能像图中红色部分“<实体>”那样，将领域服务、领域能力、值对象直接标注在方框内呢？我们可以看下另外一篇文章[《阿里巴巴技术专家三画：如何画好架构图》](https://gitbook.cn/gitchat/activity/5e9850bd6e10e519aa2334c0)这张图不仅使用颜色，还在方框顶部标识出系统的类型，显然更加友好。内外系统不仅通过颜色还通过虚线框区分。容器也会有 container 标识。非常清晰。推荐推荐几个学习作图的非常棒的网站VisualParadigm 常见UML图教程C4 软件架构可视化模型思考越是工作久了，越是应该多想想做一些事情的目的。学习知识更重要的是要内化灵活运用，不教条！！

一个基于JS的数据驱动的节点式编排组件库丰富DEMO，开箱即用全方位管理画布，开发者只需要更专注定制化的需求利用DOM/REACT/VUE来定制元素；灵活性，可塑性，拓展性优秀DEMO本地DEMOgit clone git@github.com:alibaba/butterfly.git npm install cd example npm install npm start 线上DEMO小蝴蝶官网安装npm install butterfly-dag快速上手引入方式// 完全版，内部包含jquery和lodash import {Canvas, Group, Node, Edge} from 'butterfly-dag'; import 'butterfly-dag/dist/index.css'; // 如果您引用的项目使用了jquery和lodash，为了缩小项目的体积，我们建议： import {Canvas, Group, Node, Edge} from 'butterfly-dag/pack/index.js'; import 'butterfly-dag/pack/index.css'; 生成画布import {Canvas} from 'butterfly-dag'; let canvas = new Canvas({ root: dom, //canvas的根节点(必传) zoomable: true, //可缩放(可传) moveable: true, //可平移(可传) draggable: true, //节点可拖动(可传) }); canvas.draw({ groups: [], //分组信息 nodes: [], //节点信息 edges: [] // 连线信息 }) API文档!!! 3.x的API文档，请移步到这里;画布(Canvas)节点组(Group)节点(Node)线(Edge)锚点(Endpoint)缩略图(Minimap)提示 & 菜单(tooltips & menu)布局(Layout)插件箭头(arrow)左侧画板(pannel)快捷键(hotkey)React & Vue支持React butterfly组件支持Vue2 butterfly组件支持垂直业务React拓展组件数据/字段映射组件: 适用于做数据字段映射，表字段映射，表格连线等业务表字段血缘/业务血缘: 适用于表级血缘,表字段级血缘,业务链路血缘等业务可视化建模图: 适用于UML，数据库建模，数据仓库建设等业务调度编排图(doing)监控图: 适用于任务流，数据流等业务的状态展示Butterfly-Editor(doing)如何贡献我们欢迎所有的贡献者，在成为贡献者之前，请先阅读贡献指南。如果您已经了解，快来Issus或Pull requests成为贡献者吧，让我们和小蝴蝶一起成长，一起变得更好、更棒！

原文地址：https://mp.weixin.qq.com/s/v7y6zW8JJZ-r4c7E6TDhQA1 架构图架构图就是用图形的方式表达出系统不同元素之间的关系的一种形式。元素可以有不同的粒度，如系统级别、组件级别、类级别等。2 以终为始文中提到：“不要为了画一个物理视图去画物理视图，为了画一个逻辑视图去画逻辑视图”。这点深有体会，实际工作中，我们有技术方案模板，很多人做技术方案的时候，不考虑项目的规模。有些项目规模小不需要每个图都画，不需要画的太复杂；有些人只是按照模板画图，并不清楚为什么要画这些图。因此我们画图之前要清楚为什么要画这些图，其实如何更好的表达清楚自己的意思才是最终目的。3 C4 软件架构可视化模型的逻辑C4 软件架构可视化模型的主要逻辑：（1）从整体到局部，从宏观到具体（符合人类认知规律）（2）每种图有特定的受众，针对特定的层级视角(具体文中已经给出来了)4 思考4.1 为什么不是 C3 或者 C5?是不是突然感觉像是面试中问：“为什么 HTTP 三次握手为什么是三次而不是两次？” 这种感觉？我在想，其最主要的原因于作者对用多少层可以清晰地表达架构进行了思考和取舍。C4 架构模型通过四种层级，从宏观到微观，从抽象到具体，已经可以足够表达出架构的思想。三层表达的不够全面，五层太过繁琐，四层刚刚好。4.2 C4 模型作图的痛点是啥？C4 软件架构可视化模型比传统的 UML 更简洁，有自己很成熟的逻辑。自己前一段时间也看过，也尝试画过。在画组件视图时，如果组件过多时，组件方框的排列非常耗时。自己的思考：（1）是否可以借鉴 PlantUML 那种[编码式作图]，作图效率会更高（2）或者是否可以支持类似neo4j 控制台这种图显示工具，更动态伸缩式图形展示，展示效果会更好。比如我只关心某一个控制器相关的组件，可以隐藏其他组件或者只高亮当前组件相关的其他组件。意外收获写完文章查阅官网居然发现了支持 C4 模型的 plantuml 拓展https://github.com/plantuml-stdlib/C4-PlantUML还推荐了其他工具https://c4model.com/#Tooling在这里突然想提到【先猜想后验证】的思想，有时候我们学习某种技术之前，可以先猜想它可能是怎么做的，核心逻辑应该是什么，然后再去验证是不是这样的。如果有相似之处，自己也会有些欣喜，能够多一些学习技术的乐趣；如果完全不一样，就可以比较优劣，能够印象更深刻。5 熟能生巧了解 C4 模型的核心思想之后，还要多加练习，熟能生巧。6 举一反三（1）是不是还可以从C 4 的不同层次之间抽象出一个层次，从而形成自己的 C5 C6 架构模型？（纯粹瞎歪歪）（2）我们在其他场景下，是不是可以可以借鉴 C4 模型的思想，来简化一些步骤？（3）文中提到画架构图常见的误区，如为什么用方框，实现和虚线以及颜色的含义是什么，单个图形的局限性等，给的了 C4 软件架构可视化模型的方案。文章最后说：“画之前想好：画图给谁看，看什么，怎么样不解释就看懂”。同样地，网上有很多 DDD 图形也存在一些问题。由于 DDD 中概念很多，单纯通过图形或者颜色区分，尤其在图形很大时非常容易混淆。如《DDD 的最短学习路径》 GitChat 的配图看着挺棒。或许对于作者来说，已经画了很多次，自己可以快速分辨出不同颜色的含义。为了让大家能够理解不同颜色的含义，“贴心”地在顶部提供了图例。但对于读者来说，依然需要反复核对图例来区分不同颜色的含义。那么为什么不能像图中红色部分“<实体>”那样，将领域服务、领域能力、值对象直接标注在方框内呢？有人可能会说，都写挺麻烦的啊。但是作图的目的不就是让读者能更快速而又准确地理解你要表达的意思吗？而且对于作图工具来说，同样类型的元素，我们完全可以通过复制粘贴的方式，并不是每个相同的元素都要重复敲一次 title。