天天向上 Up Up Up (*^▽^*)

设计模式总结到此为止，前面我们总共已经讲解了27种设计模式它们都是比较主流的设计模式，有自己固定的一套形式，任何语言都可以适用它们整体上可以总结为三大类 创建型模式，用于创建或复用对象 结构型模式，通过类结构的巧妙设计，来达到某种特定效果 行为型模式，通过对业务流程的抽象和设计，来实现某类特定业务除此之外，还有很多设计模式，它们不方便单独归为一类，比如 和已经总结的主流设计模式比较雷同 属于设计技巧，还不能单独归为一大类 实现代码非常之简单，没必要细讲 应用场景比较偏，不具有普适

应用场景空对象模式，英文名Null Object Pattern该模式通过一个特殊的子类或常量，来代替null，这个特殊的变量可以像正常对象一样被调用，但是它什么也不会做这种设计方式主要用来避免繁琐的空指针判断，不用去判断空指针，也不会因为失误而产生空指针异常代码实现 public interface Book { default boolean isNull() { return false; } void display(); }

应用场景规格模式，英文名Specification Pattern该模式将对产品特征的判断标准封装成规格类，专门用来判断产品是否合格这种设计模式主要用于结果判断类的业务，比如我们做单元测试时，有个概念叫做断言，和这个就是一个性质模式扩展我们可以为规格类添加Bool运算功能，使不同的规格类之间可以进行与、或、非运算，从而组合出更复杂灵活的判断条件代码实现...

应用场景桥梁模式，英文名Bridge Pattern该模式不直接定义产品类，而是以接口作为桥梁，通过若干个接口，组合成一个产品类比如一只笔，它的最终结构，是由材料、颜色、粗细等三个核心要素决定的则Pen这个产品类，可以由IMaterial、IColor、IThickness三个接口组合而成实现代码 public interface IMaterial { } public class HardMaterial implements IMaterial { @Overr

应用场景享元器模式，英文名Flyweight Pattern该模式通过对象复用，来避免大量创建复杂对象主要用于线程池，连接池等场景，实现上比较简单代码实现 public class Product { } //每种类型的产品，共享一个对象 public class ProductFactory { //对象复用池 private static final Map<String, Product> pool = new HashMap();

应用场景解释器模式，英文名Interpreter Pattern这是一个比较专业的模式，它专门用于公式解析或语法解析类的问题该模式通过一个专门的解释器类，根据用于输入的表达式和参数，来计算出运算结果该模式并没有固定形式，解释器如何实现完全取决于实际问题但大多公式和语法类问题，解决方法都会涉及递归运算、栈、二叉树等知识实现代码这里以加减法为例，实现一个最简单的公式解释器 //数学表达式 //一个总的表达式，可以视为若干个子表达式，进行多次组合运算后得到的结果 //这样我们就可以抽象出表达

使用场景状态模式，英文名State Pattern该模式根据对象状态来决定对象行为，由State来决定行为，而不是Context自身这种设计模式的目的在于，将与状态切换相关的工作，交给State自己处理，Context只关心自身的其它业务根据业务复杂程度，该模式可以有简单和复杂两种实现方式 简单模式下，每个状态之间是独立的，每个State对象直接处理当前状态下的工作即可，不需要考虑旧状态 复杂模式下，多个状态之间是有关联的，从旧状态切换到新状态，需要做一些额外的切换工作，并且不同状态之间的切换

应用场景访问者模式，英文名Visitor Pattern该模式通过一个访问类，来集中实现对不同类型数据的访问或操作该模式的优点是，旧的类只需实现一个被访问者接口，不用修改修改旧代码，就能被Visitor访问适合需要对大量、类型不同的数据，进行集中访问的场景代码实现 public interface IBook { void onVisit(Visitor visitor); } public class BookA implements IBook { pu

应用场景备忘录模式，英文名Memento Pattern该模式将对象状态封装为一个对象，再通过一个状态管理器对象将状态保存起来，这样就可以实现状态还原功能该模式主要用于状态回滚的业务场景代码实现 public class State { String attribute1; String attribute2; String attribute3; } public class Saver { LinkedList<State>

应用场景门面模式，英文名Facade Pattern该模式通过一个门面对象，来统一访问系统内的所有对象该模式的优点是 减少对系统内部对象的依赖，增强代码安全性 用户只能访问门面对象提供的接口，不能接触到系统内部实现使用该设计模式，一般出于以下目的 为一个复杂的模块或子系统提供对简单的外访问接口 模块或子系统相对独立，不需要被外部了解 预防低水平人员带来的代码修改风险，禁止修改模块内部代码代码实现 public class A { public void exec

发布订阅模式发布订阅模式，英文名Publish Subscribe Pattern该模式通过一个中间调度者，将发布者发布的动态，转发给订阅者它和观察者模式在功能上非常相似，不同的地方在于观察者模式是由Observable直接通知Observer而发布订阅模式则有一个扮演调度中心角色的中介者，专门负责转发事件通知实现代码 public class EventBus { Map<String, List<Subscriber>> subscriberMap

观察者模式观察者模式，英文名Observer Pattern该模式用于一个对象通知另一个对象，某事件发生通知的对象扮演的角色叫做主体或被观察者（Subject或Observable）被通知的对象扮演的角色叫做观察者（Observer）该模式主要用于事件通知或事件联动类的业务Observer和Subject之间是解耦合的，仅通过一个通知函数联系起来实现代码 public class Subject { List<Observer> observers = new A

应用场景组合模式，又叫部分整体模式，英文名Composite Pattern该模式将所有对象视为树状结构中的一个节点，所有对象的结构是完全一致的，且具备容器的功能，每个节点都可以再包含多个子节点这种模式可以用来实现上级-下级，或是整体-部分的关系组合模式有两种实现方式 一种是通过一个统一的节点类，来表示所有对象，任何一个对象都可以拥有上级节点，或添加下级节点 另一种是将根节点、枝节点、叶节点分别用三种不同的类来表示，根节点不允许拥有上级节点，叶节点不允许添加下级节点第一种更加灵活，因为大多

应用场景迭代器模式，英文名Iterator Pattern该模式专门提供一个类，来访问和管理容器中的对象该模式优点是可以屏蔽容器的实现细节，用户只需关心迭代功能本身，对于复杂的容器类来说，尤其实用实现代码 @SuppressWarnings("all") public class Iterator { List container = new ArrayList(); int cursor = 0; public Iterator(List conta

应用场景适配器模式，英文名Adapter Pattern该模式将一种类/对象/数据，适配为另一种预期的类/对象/数据，这样两种不同性质的类/对象/数据就可以同时工作该模式的优点是，不用修改源角色和目标角色的代码，只需要修改或创建新的适配器，就可以完成转换功能在实际应用中，只要是扮演转换功能的角色，都可以称之为适配器，没有绝对的形式要求但主要的应用形式，一般有以下几种类适配器适配器继承自源角色，同时实现目标角色接口，这样就可以同时控制两种角色的功能至于是targetWork调用originWo

应用场景策略模式，英文名Strategy Pattern该模式将一组算法（业务方案）封装起来，使用时根据需要动态切换对应的算法去解决问题该模式的优点是，方案可以自由切换，动态插拔，不必使用许多if-else来判断如何处理一般适用于以下场景 解决方案有多种，需要自由切换 不希望方案细节暴漏给使用者，使用者直接调用现成对象即可代码实现一 public interface Strategy { void resolve(); } public class Strateg

使用场景装饰模式，英文名Decorator Pattern该模式通过一个装饰类来包裹一个核心组件类，这样装饰类既可以使用组件的功能，也可以做一些额外的扩展工作采用这种设计模式，一般可能出于以下几种原因核心组件类不允许继承或重写只是偶然需要做一些扩展工作，并没有复用价值，没必要再继承一个类实现代码 public class Component { public void work() { } } public class ComponentDecorator

应用场景责任链模式，英文名Responsibility Chain Pattern该模式将多个接收者连接成一条处理链，请求依次经过这些接收者，直到有接收者处理它这种模式将请求和处理解耦开来，并且允许存在多个处理者，可以很灵活地决定谁去处理，如何处理我们只要对齐稍加修改，就可以实现更加高级灵活的功能，比如多个接收者依次对请求进行处理，每个接收者只负责处理请求的一部分接收者可以对请求进行拦截，决定后面的接收者要不要继续对请求进行处理请求类可以扮演一个初级产品的角色，处理者可以扮演一个加工者的角色

使用场景命令模式，英文名Command Pattern该模式在处理工作时，不是直接去处理，而是将工作封装为一系列的命令，交给接收者去处理这样做的好处是，工作是难以记录的，但命令是可以记录的将这些命令记录起来，就可以实现日志、撤销、恢复、重做等功能实现代码 //任务执行者 //执行者并不是自己去执行，而是将任务转给对应的接收者去处理 public class Invoker { LinkedList<Command> commands = new LinkedLis

使用场景中介者模式，英文名Mediator Pattern该模式通过一个中介对象，来统一管理对象之间的交互而不是在一个对象的类代码中直接与另一个类对象直接进行交互这样就可以在不修改类定义，只修改类之间的交互代码，达到了解耦效果使用情景需要通过一个控制中心的角色，统一管理和调度所有资源间的交互实现代码 public class StoreA { public int count; } public class StoreB { public int c

应用场景原型模式，英文名Prototype Pattern该模式通过内存拷贝的方式，快速复制出一个新对象，而不是通过构造方法重新去构建使用情景主要有以下几种性能要求高，对象创建频繁，通过内存拷贝的方式可以大幅提升性能对象构建过程很复杂，不如直接拷贝生成，然后再修改个别字段新对象的初始化，完全继承自上个对象，可以直接拷贝，没必要再建一个空对象逐个赋值实现代码在Java中，内存拷贝主要是通过clone函数来实现的这是一个native方法，必须实现Cloneable接口后才可使用通过clo

应用场景代理模式，英文名Proxy Pattern该模式用一个代理类代替原始类进行工作使用这种模式，一般是出于以下几种目的对原始类的功能进行增强、拦截、修改控制原始类的访问权限分担原始类的工作负荷凡是能起到代理工作作用的方式，都可以认为是代理模式，所以它的实现也是多种多样的我们现在只列举几种主流的实现形式普通代理代理类包装了一个原始类，并且实现了和原始类一样的接口，但代理类调用原始类来处理工作 public interface IAction { void hand

使用场景建造者模式，英文名Builder Pattern该模式使用一个单独的类，来封装对象的构建过程适用场景：对象构建或初始化工作特别麻烦，让用户手动去构建或初始化很容易出错，或者要调用特别多的函数建造者模式和工厂模式的区别单从功能上来说，建造者模式和工厂模式的功能很像但如果大家两种模式都使用过，就会发现区别还是特别大的，很容易区分工厂模式侧重于集中生产产品对象，是对多种产品的一种集中管理，产品对象的创建工作往往很简单建造者模式则是侧重于构建单个对象，使用这个模式，往往是由于单个对象的构建

应用场景模板方法模式，英文名Abstract Method Pattern该模式在基类中定义了通用业务流程，在子类中实现具体的子流程适用场景：整体流程固定，但某个子流程有多种实现方式实现代码 abstract public class Biz { public void go() { step1(); step2(); step3(); } protected void step1() { }

应用场景抽象工厂模式，英文名Abstract Factory Pattern抽象工厂模式是工厂模式的一种升级版本，它能够支持更为复杂的业务抽象工厂可以生产多种产品，而不再只是生产一种产品实现代码 //产品A abstract public class ProductA { } public class ProductA1 extends ProductA { } public class ProductA2 extends ProductA { }

应用场景工厂模式，英文名Factory Pattern该模式通过专门的接口或类来创建对象，而不是直接new出对象使用这种模式的原因一般主要有以下几种一是对象创建较为繁琐，因此提供一个工具类进行快速创建二是对象创建时对参数有一定要求，所以需要工具类来进行统一管理三是创建对象时，需要做一些额外的工作，比如统计对象使用情况，使用缓存策略等工厂模式根据具体应用场景和业务复杂度，也有多种形式的实现方式实现一最简单的情况，直接通过工厂类生产商品 public class Product {

应用场景单例模式，英文名Singleton Pattern它规定一个类只有一个实例化对象，并且提供获取唯一实例的方法使用这种模式一般有两种可能性一是希望节省内存，避免重复创建内容相同的对象二是在业务上，该类的对象属性是固定的，比如SystemConfig类，创建多份操作不当容易造成数据不一致单例模式有很多中实现方式，只要能保证类实例唯一，都是单例模式实现一单例模式的标准写法 public class SingletonTestA { //唯一实例 privat

前言不管是那种设计模式，或者是不涉及任何设计模式的普通代码，都应当遵循一些通用的设计准则一般有以下几种单一职责原则每个接口只负责一类功能，如果一个类包含多个类别的属性和行为，应该分成多个接口实现子类可替换原则（里氏替换原则）只要可以使用父类的地方，都可以使用子类，并且替换成任何子类，程序都不会产生异常依赖倒置原则这个原则包含两层意思一层是：模块之间的依赖关系，应当通过接口来定义，而不是在实现类中定义另一层是：子类可以依赖父类，但是父类不能依赖子类接口隔离原则模块不应当和多余的接口产生

关于设计模式总共有多少种，这个是没有具体标准的因为有些模式应用情景比较少，有些模式之间原理相似有些模式又可以有多种实现方式，可能会演变成其它名称的设计模式因此设计模式之间是没有明显界限的重点在于理解每个设计模式的核心思想，然后自己灵活综合运用每个设计模式，也可能有它自身的一些缺点，需要根据实际需要进行取舍或综合使用