花了30天才肝出来，史上最全面Java设计模式总结，看完再也不会忘_Tom弹架构

Tom弹架构：为什么一定要学习设计模式

Tom弹架构：开闭原则（Open-Closed Principle，OCP）

Tom弹架构：依赖倒置原则（Dependence Inversion Principle，DIP）

Tom弹架构：单一职责原则（Simple Responsibility Principle，SRP）

Tom弹架构：接口隔离原则（Interface Segregation Principle，ISP）

Tom弹架构：迪米特法则（Law of Demeter，LoD）

Tom弹架构：里氏替换原则（Liskov Substitution Principle，LSP）

Tom弹架构：合成复用原则（Composite/Aggregate Reuse Principle，CARP）

Tom弹架构：简单工厂模式(Simple Factory Pattern) >> 彻底说透简单工厂那些你没有关注过的细节

Tom弹架构：工厂方法模式（Factory Method Pattern）>> 全面通透深入剖析工厂方法模式

Tom弹架构：抽象工厂模式（Abstract Factory Pattern）>> 手写数据库连接池，让抽象工厂不再抽象

Tom弹架构：单例模式（Singleton Pattern）>> 这9个单例被破坏的事故现场，你遇到过几个?

Tom弹架构：原型模式（Prototype Pattern）>> 一文读懂深克隆与浅克隆的关系

Tom弹架构：建造者模式（Builder Pattern）>> 用建造者模式实现一个防SQL注入的ORM框架

Tom弹架构：代理模式（Proxy Pattern）>> 从没有人将代理模式分析得如此透彻

Tom弹架构：门面模式（Facade Pattern）>> 原来你不知道自己每天都在用门面模式

Tom弹架构：装饰器模式（Decorator Pattern）>> 趣谈装饰器模式，让你一辈子不会忘

Tom弹架构：享元模式（Flyweight Pattern）>> 就因为把int改成Integer，第2天被辞了

Tom弹架构：组合模式（Composite Pattern）>> 没有性能瓶颈的无限级菜单树应该这样设计

Tom弹架构：适配器模式（Adapter Pattern）>> 高效接入第三方登录且易扩展的方法

Tom弹架构：桥接模式（Bridge Pattern）>> 使用桥接模式设计复杂的消息系统

Tom弹架构：委派模式（Delegate Pattern）>> 你以为委派模式很神秘，其实你每天都在用

Tom弹架构：模板方法模式（Template Method Pattern）>> 搞懂钩子方法和模板方法，看完这篇就够了

Tom弹架构：策略模式（Strategy Pattern）>> 使用策略模式重构电商折扣和支付场景

Tom弹架构：责任链模式（Chain of Responsibility Pattern）>> 这才是责任链模式的优雅使用方式

Tom弹架构：迭代器模式（Iterator Pattern）>> 手写自定义迭代器，秒懂迭代器底层原理

Tom弹架构：命令模式（Command Pattern）>> 使用命令模式重构播放器控制条

Tom弹架构：状态模式（State Pattern） >> 彻底搞懂Spring状态机原理，实现订单与物流解耦

Tom弹架构：备忘录模式（Memento Pattern）>> 只要100行代码，实现文本编辑器中的草稿箱功能

Tom弹架构：中介者模式（Mediator Pattern）>> 微信和QQ这么多群，该如何管理好友关系？

Tom弹架构：解释器模式（Interpreter Pattern）>> 这个无敌设计，可以解析并运算任意数学表达式

Tom弹架构：观察者模式（Observer Pattern）>> 基于Guava API实现异步通知和事件回调

Tom弹架构：访问者模式（Visitor Pattern）>> 彻底搞懂访问者模式的静态、动态和伪动态分派

Tom弹架构：对象池模式（Object Pool Pattern）

Tom弹架构：规格模式（Specification Pattern）

Tom弹架构：空对象模式（Null Object Pattern）

Tom弹架构：雇工模式（Employee Pattern）

1. 都属于创建型设计模式。
2. 职责相同

所创建产品的扩展程度不同：工厂方法模式只能单向维度扩展产品；而抽象工厂模式可以让产品等级结构和产品族的相互扩展，而且可以多维度扩展（至少是二维扩展）

抽象工厂很多时候不一定是接口，而是抽象类；工厂方法类一般作为抽象工厂类的子类

从类图上看，抽象工厂模式中的抽象产品可以是多个维度的，而工厂方法模式中的抽象产品是单维度的。因此抽象工厂模式中的产品可以支持多维度扩展，而工厂方法模式中的产品只能单维度扩展。一个抽象工厂可以创建同一产品族下的多个抽象产品，而工厂方法模式并没有引入产品族的概念，只要是抽象产品的实现类都可以创建

1.都属于创建型设计模式。
2.都会提供对外的获取对象的方法

职责不同：单例模式的职责是确保一个类在Java虚拟机里只有一个对象，整个系统共享这个对象；简单工厂模式的职责是封装对象的创建细节

在实际业务代码中，通常把工厂类设计为单例对象

从类图上看，单例模式和简单工厂模式并没有直接的关联

1. 都属于创建型设计模式。
2. 职责相同，都是将创建产品的细节封装起来

1. 目的不同：简单工厂模式关注创建一个完整的标准产品，而建造者模式更关注创建个性化的产品。
2. 产品的复杂度不同：简单工厂模式创建的一般都是单一性质的产品，建造者模式可以创建复合型产品。一般来说，简单工厂模式创建的产品对象粒度比较粗，建造者模式创建的产品对象粒度更细

在实际业务代码中，通常把工厂类设计为单例对象

从类图上看，建造者模式比简单工厂模式多了一个建造者类。对于客户端而言，用户在调用build()方法之前都只是对产品参数的预设。而在简单工厂模式中，没有预设参数的动作，直接调用创建产品的方法获取产品的实例

1. 都属于结构型设计模式。
2. 都是包装器模式的实现。
3. 都是为了达到功能增强的目的

1. 实现形式不同：代理模式通过组合实现功能增强和扩展，装饰器模式通过继承实现增强和扩展。
2. 目的不同：代理模式着重代理的过程控制，而装饰器模式则是对类功能的加强或减弱，更注重类功能的变化。
3. 可扩展程度不同：装饰器模式的代码扩展灵活度更大，代理模式的扩展相对来说依赖性更强

装饰器模式可以说是静态代理模式的一个特殊应用

从类图上看，装饰器模式中会设计一个抽象的组件，后面不管是装饰器还是具体的组件，都是抽象组件的实现类，属于同一继承体系，功能扩展是在具体的装饰器中完成的。而代理模式用的是硬编码，功能的扩展简单粗暴

1.都属于创建型设计模式。
2.都是包装器模式的实现

目的不同：装饰器模式的主要目的是统一多个子系统的访问入口，承担一定的静态代理作用，大部分时候也会用到委派模式。装饰器模式的主要目的是功能扩展，而且扩展的类与目标类一定是同宗同源的

从代码结构上看，二者都是包装器模式的一种实现，二者也都会用到静态代理

从类图上看，门面模式中的门面类更像是一个万能的类，看上去涵盖了所有子系统的功能。而装饰器模式更符合单一职责原则

1. 都属于结构型设计模式。
2. 都是包装器模式的实现

1. 代码结构不同：装饰器模式包装的都是自己的兄弟类，同宗同源；而适配器模式则是将一个非本家族的对象伪装起来。
2. 设计目的不同：适配器模式的意义是将一个接口转变成另一个接口，通过改变接口来达到重复使用的目的；而装饰器模式不是要改变被装饰对象的接口，而是恰恰要保持原有的接口，但是增强原有对象的功能，或者改变原有对象的处理方式，从而提升性能

装饰器模式和适配器模式只有结构上容易混淆，在具体业务场景中还是很容易区分的

从类图上看，没有太多的相似点。装饰器模式多了一个抽象装饰者，便于子类扩展。而适配器模式没有抽象装饰者这一层，直接扩展接口

1. 都属于结构型设计模式。
2. 都是包装器模式的实现。
3. 二者都起到了隐藏和保护原类的作用

目的不同：适配器模式主要解决兼容问题，会保留被适配对象已经存在的方法并继续对外开放调用；而代理模式主要是为了功能增强，目标类的方法不会直接提供给用户调用，而是调用代理类的方法获得增强后的结果

对象适配器就是静态代理的一种实现

从类图来看，代理模式中的目标类和代理类继承同一父类，而适配器模式中只有适配器类才继承目标接口

1. 都属于行为型设计模式。
2. 都可以用来分离高层的算法和低层的具体实现细节，允许高层的算法独立于它的具体实现细节重用

1. 开放程度不同：策略模式允许外界调用其接口方法，而模板方法模式则限制接口方法只能在子类调用。
2. 方法控制权不同：模板方法模式采用继承的方式实现算法的异构，其关键点就是将算法封装在抽象基类中，并将不同的算法实现细节放在子类中实现，控制权在用户。而模板方法模式符合依赖倒置原则，父类调用子类的操作，底层模块实现高层模块声明的接口。这样控制权在父类，底层模块要依赖高层模块

有时候会混合使用，模板方法模式中可能设计的钩子方法，就是某一个策略的实现

从类图来看，在策略模式中的策略类，是实现策略抽象接口的全部方法。而在模板方法模式中，具体的实现类只实现模板类的部分方法，模板类通常为抽象类，而非接口

1. 都属于行为型设计模式。
2. 都需要对外提供一个功能清单给用户选择

业务场景不同：当不使用命令模式时，请求和处理的代码是写在一起的，但通常会降低调用者的体验，因此命令模式通常用于解耦请求和处理的场景。使用命令模式一般会有一个回调，反馈和处理结果。而策略模式则是封装算法，提供固定好的选项，让用户参与到业务的执行过程中，选择不同的策略最终会得到同一类型的结果。因为每一种策略都是可以相互替换的

命令模式内部的有些逻辑处理可以设计成策略模式

从类图来看，一个命令在形式上很像一种策略。只是命令模式多了一个接收者角色。但是在命令模式中，每条命令都是不能相互替换的，而在策略模式中，每种策略都是可以相互替换的

都属于行为型设计模式

关注点不同：策略模式关注策略是否能相互替代，而委派模式更关注分发和调度的过程

委派模式内部通常会用到策略切换的上下文容器

从类图上看，策略模式中上下文容器只是算法策略的选择切换所在，不需要实现策略接口。委派模式中委派者和被委派者实现了同一个接口

1. 都属于行为型设计模式。
2. 代码组织结构类似：适配器模式和桥接模式都是间接引用对象，因此可以使系统更灵活，在实现上都涉及从自身以外的一个接口向被引用的对象发出请求

1. 适用场景不同：适配器模式主要解决已有接口间的兼容问题，被适配的接口实现像是一个黑匣子，我们不想也不能修改这个接口及其实现，也不可能控制其演化，只要相关的对象能与系统定义的接口协同工作即可。适配器模式经常被用在与第三方产品的功能集成上，采用适配器模式适应新类型的增加的方式是开发针对这个类型的适配器。桥接模式则不同，参与桥接的接口是稳定的，用户可以扩展和修改桥接中的类，但是不能改变接口。
2. 设计原则不同：桥接模式不使用继承建立联系。而适配器模式中类适配器写法用的继承，对象适配器写法用的组合，接口适配器写法实际上用的也是继承，与桥接模式有由根本区别

按照GoF的说法，桥接模式和适配器模式用于设计的不同阶段，桥接模式用于设计的前期，即在设计类时将类规划为逻辑和实现两个大类，是它们可以分别精心演化的；而适配器模式用于设计完成之后，当发现设计完成的类无法协同工作时，可以采用适配器模式。然而很多情况下在设计初期就要考虑适配器模式的使用，如涉及大量第三方应用接口的情况

从类图上看，桥接模式比适配器模式更复杂，实际上多了一个桥接角色

都属于行为型设计模式

目的不同：桥接模式的目的是将两个继承体系建立连接，是为了满足个性的需求的。而组合模式的目的不是建立连接，而是统一行动，统一成同一套API便于整体操作

桥接模式和组合模式关联性不大

从类图上看，桥接模式相对组合模式而言，其类图要复杂得多。桥接模式中抽象和实现不使用继承。而在组合模式中，所有的节点都具有共同的抽象，只有这样才能够统一操作

1. 都设计了一个缓存对象的容器。
2. 设计目的有相似之处，两者都是为了节省内存开销

1. 类型不同：享元模式属于结构型设计模式，容器式单例模式属于创建型设计模式。
2. 对创建对象的控制粒度不同：享元模式可以再次创建对象，也可以取缓存对象。而单例模式则严格控制应用程序中只有一个实例对象。
3. 实现形式不同：享元模式可以通过自己实现对外部的单例，也可以在需要的时候创建更多的对象；单例模式是自身控制，需要增加不属于该对象本身的逻辑

享元模式可以看成是单例模式的扩展，可以把对象池的容器设置为单例。同时，把对象池所在的类设置为单例的工厂。
享元模式 = 单例模式 + 工厂模式 + 组合模式

从类图上看，享元模式的类图比单例模式要复杂，但是都提供了一个获取对象的方法

都有扩展装饰的作用

1.类型不同：建造者模式属于创建型设计模式，装饰器模式属于结构型设计模式。
2.应用场景不同：建造者模式针对构建复杂对象，且构建过程不稳定，强调对象创建步骤的个性化，一般来说会有标配；而装饰器模式针对建造过程十分稳定的情况，采用大桶套小桶

二者很少会出现混合使用的情况

从类图上看，并没有太多的相似点

客户端调用方式相同：两者都是通过传入参数进行配置的。

1.类型不同：策略模式属于行为型设计模式，简单工厂模式属于创建型设计模式。
2.侧重点不同：简单工厂模式则是通过传参选择创建出需要的对象，而策略模式则是通过传参配置出需要的行为算法。一个是对象创建，另一个是行为算法的替换。
3.设计逻辑不同：两者的差别很微妙，简单工厂模式是直接创建具体的对象并用该对象去执行相应的动作。而策略模式设计一个上下文（Context）类，将操作给了上下文类，策略类内部没有创建具体的对象，从而实现代码的进一步封装，客户端代码并不需要知道具体的实现过程

一般来说，二者会组合使用，具体策略将由工厂来创建

从类图上看，策略模式和简单工厂模式非常相似，都通过多态来实现不同子类的选取，这种思想应该是从程序的整体看出来的

都是通过找到已经存在的、运行良好的类来实现接口的

1. 类型不同：策略模式属于行为型设计模式，适配器模式属于结构型设计模式。
2. 目的不同：策略模式把一系列算法封装起来，提供一个统一的接口给客户，并使这些算法可以相互间替换；而适配器模式将一个类的接口转换成客户希望的另外一个接口，从而使原本因接口不兼容不能一起工作的类可以一起工作。
3. 客户单端调用方式不同：策略模式的所有策略都需要暴露出去，由客户端决定使用哪一种策略。而适配器模式是定义好接口的实现方式及内部需要引用的类，客户端直接调用适配器的方法

策略模式很多时候都和适配器模式结合使用，把具体适配器作为具体策略，用户选择不同策略从而调用不同的适配器方法

从类图上看，策略模式中方法的形参为接口对象，实参为接口的实现类。而适配器模式中在适配器中定义适配者来辅助实现接口

二者本质上都是一样的，在一个类中调用另一个类中的方法，从而减少耦合

1.类型不同：中介者模式属于行为型设计模式，适配器模式属于结构型设计模式。
2.目的不同：中介者模式主要完成资源协调，而适配器模式主要解决兼容问题。
3.代码结构不同：中介者模式一定是用组合的形式实现代码复用的，所有人可能都持有中介者的引用：而适配器模式可以用继承的方式实现，也可以用组合的方式来实现代码复用

二者并没有明显的关联性

从类图上看，适配器采用的是对象适配器的类图，适配者和被适配者是组合复用的关系。中介者模式中具体的同事类都是持有中介者的引用。适配者和中介者都实现了一个接口（抽象）

都具备保护目标对象的特性

1. 类型不同：中介者模式属于行为型设计模式，代理模式属于结构型设计模式。
2. 干预程度不同：如果说代理模式是“媒婆”，那么中介者模式就是“不负责任的媒婆”。
3. 职责不同：代理模式的职责是功能增强，不仅要将目标对象和代理对象建立联系，代理对象还要参与过程。而中介者模式中的中介者只负责牵线搭桥，建立联系，不参与具体的过程

中介者模式是一种面向更加复杂的对象关系的全权静态代理（委托）

从类图上看，Proxy类和Mediator都具备中介的功能，可以达到保护目标类的作用

都具备将两个对象建立联系的特性

1.类型不同：中介者模式属于行为型设计模式，桥接模式属于结构型设计模式。
2.适用场景不同：桥接模式只适用于将两个维度建立连接；而中介者模式可以将多个维度建立连接

中介者模式是一种更为复杂的桥接模式，中介者可以和网状结构的对象建立连接，而桥接模式只能和两个维度的对象建立连接

从类图上看，中介者模式和桥接模式还是非常相似的，只是中介者模式中采用的是组合复用，而桥接模式中采用的是继承复用。可以说中介者模式是桥接模式的升级版

都是为了达到解耦的目的

1.类型不同：桥接模式属于结构型设计模式，命令模式属于行为型设计模式。
2.目的不同：桥接模式需要一个中间的实现类，以达到抽象和具体之间解耦的目的。而命令模式需要一个抽象的中间类，只是为了规范，达到请求和处理解耦的目的

桥接模式和命令模式组合使用的场景不常见

从类图上看，桥接模式通过抽象角色来与抽象维度和具体维度建立连接，而命令模式通过封装命令对象，将调用者角色和接收者角色建立连接，二者分别适用于不同的业务场景

从代码结构上看，都是包装器模式，也是一种静态代理，都具有包装对象的特性

1.类型不同：委派模式属于行为型设计模式，门面模式属于结构型设计模式。
2.侧重点不同：委派模式针对行为上的统一调度和分发，而门面模式是针对组织结构上的统一入口

在门面模式中，可能会用到委派模式实现任务分发

从类图上看，委派模式和门面模式非常相似，只是在委派模式中多了一个接口，而门面模式没有一个公共的接口

都有保护目标对象的特性

1.类型不同：委派模式属于行为型设计模式，代理模式属于结构型设计模式。
2.职责不同：委派模式虽然结构上是一种全权的静态代理，但对目标类的功能不做任何的增强；而代理模式中的代理类一定会对目标类进行功能增强

委派模式就是全权的静态代理，不做任何的代码增强

从类图上看，委派模式和代理模式几乎一致。只是委派模式是一个类代理多个目标类，而代理模式是一个类只代理一个目标类