设计模式的七大原则

1. 开闭原则：对扩展开放、对修改关闭。
2. 单一指责原则：一个类只做一件事。
3. 依赖倒转原则：类似于ioc，采用接口编程。
4. 迪米特原则：高内聚，低耦合。
5. 接口隔离原则：应该使用多个接口，而不是用单一的总接口。
6. 合成复用原则：尽量使用对象组合，而不是继承来达到复用目的。
7. 里氏替换原则：子类可以扩展父类的功能，但不能改变原有的功能。

一、创建型模式（5种）

1、单例模式（Singleton）

保证一个类只有一个实例，并提供一个全局访问点。

有四种单例实现方式：java设计模式之单例模式singleton_现实、太残忍的博客-CSDN博客

2、工厂模式（Factory）

把对象的创建功能交给工厂，达到解耦目的。

适合场景：

1. 无法预知对象确切类别及依赖关系时，可使用。
2. 希望复用现有对象来节省系统资源，而不是每次都创建对象。

3、抽象工厂模式（Abstract Factory）

用于创建一系列相关的对象， 而无需指定其具体类

适合场景：

1. 如果代码需要与多个不同系列的相关产品交互，由于无法提前获取相关信息或未来扩展考虑，不希望代码基于产品的具体类来进行构建的情况下使用。
2. 当有一个基于一组抽象方法的类，且其主要功能不明确时，可以使用。

用例：spring的BeanFactory。和其他任何用于创建对象但返回接口或抽象类的就是此模式。

搭配模式：策略模式

4、生成器模式（Builder）

定义一个类来简化复杂对象的创建（分步骤创建）。该类是为了构建另一个类的实例。

适合场景：

1. 避免“重叠构造函数”的出现。
2. 当希望用代码创建不同形式的产品时使用。
3. 比如订单系统，订单对象就是一个复杂对象，我们就可以build来做。

用例：SpringApplicationBuilder、StringBuilder

5、原型模式（prototype）

使你能够复制已有对象， 而又无需使代码依赖它们所属的类。

适合场景：

1. 创建一个对象的实例非常复杂且耗时时可以使用
2. 例如我们的DTO、BO、DO、VO转换时可以使用

用例：spring的bean有单例模式singleton和原型模式prototype（scope=prototype）

二、结构型模式(7种)

1、代理模式（Proxy）

代理控制着对于原对象的访问（不能直接访问原对象）， 并允许在将请求提交给对象前后进行一些处理。

适合场景：

1. 用于保护原对象
2. 用于增强原对象

用例：jdk的Proxy类

2、适配器模式（Adapter）

用于新接口和旧接口的适配，使接口不兼容的对象能够相互合作。

适合场景：

1. 希望使用某类，但与接口或其他代码不兼容时使用

用例：springmvc的HandlerAdapter。例如xml转json，可以新增XmlJsonAdapter适配器类内进行转换

3、桥接模式（bridge）

将抽象和抽象的具体实现进行解耦，使得抽象和抽象的具体实现可以进行独立变化。并使用组合的方式将多维度的抽象方法联系在一起

适合场景：

1. 想要拆分或重组一个具有多重功能的庞杂类（例如多个能与数据交互的类）可使用。
2. 想在几个纬度上扩展类。
3. 想要在运行是切换不同实现方法。

4、组合模式(composite)

可以使用它将对象组合成树状结构，以表示“部分-整体”的层次结构， 并且能像使用独立对象一样使用它们。

让客户端看起来在处理单个对象和对象的组合是平等的，换句话说，某个类型的方法同时也接受自身类型作为参数。例如Map的putAll（Map）方法

适合场景：

1. 需要实现树状对象结构时。
2. 希望客户端代码以相同方式处理简单和复杂元素时。
3. 常用于递归操作的优化上

实例：

5、外观模式/门面模式（Facade）

为一组接口、抽象类或子系统提供简化的接口。并且要求一个子系统的外部与其内部的通信必须通过一个统一的Facade对象进行。

Facade模式提供一个高层次的接口，使得子系统更易于使用

适合场景：

1. 需要一个指向复杂子系统的直接接口，但使用的功能有限时。
2. 子系统组织为多层结构时。
3. 保护子系统的接口，可以使用门面模式只提供某些接口，不提供全部。
4. 使用Dubbo，向外提供的服务就尽量采用门面模式，然后服务在调用各种service做聚合

实例：

1. tomcat的RequestFacade
2. SLFJ日志就是门面日志

6、装饰模式(Decorator/Wapper)

你通过将对象放入包含行为的特殊封装对象中来为原对象绑定新的行为。相当于动态的给一个对象附加额外的功能，因此它也是子类化的一种替代方法。（就是在不继承的情况下，扩展类的功能）

实例：

1. tomcat对request的包装ServletRequestWrapper
2. 所有的io流包装类

7、享元模式(Flyweight)

它摒弃了在每个对象中保存所有数据的方式， 通过共享多个对象所共有的相同状态， 让你能在有限的内存容量中载入更多对象。

简单来说就是使用缓存来减小对象的访问时间（使用共享技术实现元素的共享）

适合场景：程序必须支持大量对象且没有足够的内存容量时使用（共享变量）

实例：

1. 只要用到了缓存，基本都是在使用享元模式

三、行为型模式（12种）

1、责任链模式（Chain of Responsibility）

将请求沿着处理者链进行发送。 收到请求后， 每个处理者均可对请求进行处理， 或将其传递给链上的下个处理者。

可以实现解耦。责任链中的对象是同一接口或抽象类的不同实现。

适合场景：

1. 程序需要用不同的方式处理不同请求，而且请求类型和顺序未知时。
2. 当必须按照顺序执行多个处理者时。
3. 如果所需处理者及其顺序必须在运行时进行改变时。

用例：

1. servler中Filter过滤器
2. 拦截器等

2、命令模式（Command）

将命令包装在对象中，以便可以存储、传递到方法中，并像任何其他对象一样返回(以命令动作为类名)

命令模式可以把发出命令的责任和执行命令的责任分开。

适合场景：

1. 需要通过操作来参数化对象。
2. 想要将操作放入队列中，本地执行操作或远程执行操作时，可以使用。
3. 想要实现操作回滚功能时。

用例：

1. java.lang.Runnable
2. javax.swing.Action

3、迭代器模式（Iterator）

让你能在不暴露集合底层表现形式 （列表、 栈和树等） 的情况下遍历集合中所有的元素。

提供一个统一的方式来访问集合中的对象。

适合场景：

1. 当集合背后时复杂的数据结构，希望对客户端隐藏时（处于便利性或安全性）
2. 可以监视程序中重复的遍历代码时
3. 希望遍历不同，甚至是无法预知的数据结构时。

用例：

1. Iterator
2. Vector集合
3. set集合

4、中介模式（Mediator）

能让你减少对象之间混乱无序的依赖关系。 该模式会限制对象之间的直接交互， 迫使它们通过一个中介者对象进行合作。（用一个中介对象来封装一系列关于对象交互行为）

即使用一个中间对象来进行消息分发以及减少类之间的直接依赖

适合场景：

1. 当一些对象或其他对象紧密耦合难以对其进行修改时。
2. 当组件过于依赖其他组件而无法在不同应用中复用时。
3. 如果为了能在不同情景下复用一些基本行为，而导致需要被迫创建大量组件子类时。

用例：

1. mq使用的就是此模式
2. MVC中的Controller
3. Executor

5、备忘录模式（Memento）

允许在不暴露对象实现细节的情况下保存和恢复对象之前的状态。

即生成对象状态的一个快照，以便对象可以恢复原始状态而不用暴露自身的内容。

在不破坏封装性的情况下，捕获并保存一个类的内部状态，可以利用该保存的状态实施恢复操作。

适合场景：

1. 当你需要创建对象状态快照来恢复其之前的状态
2. 当直接访问对象的成员变量、get、set时导致封装被突破时

用例：

1. Date对象通过自身内部的一个long值来实现备忘录模式
2. Serializable

6、观察者模式/发布订阅模式（Observer/Listener）

允许你定义一种订阅机制， 可在对象事件发生时通知多个 “观察” 该对象的其他对象。

适合场景：

1. 当一个对象的改变需要改变其他对象时，或实际对象时事先未知的或动态变化的时。
2. 当应用中的一些对象必须观察其他对象时。

用例：

1. EventListener
2. tomcat的LifeCycleListener
3. 使用zookeeper作为观察者，例如分布式锁、服务发现等

7、状态模式（State）

能在一个对象的内部状态变化时改变其行为， 使其看上去就像改变了自身所属的类一样。

即允许您在运行时根据内部状态轻松更改对象的行为。

状态模式重点在各状态之间的切换从而做不同的事情，状态模式不同状态下做的事情不同。

状态模式封装了对象的状态，因为状态是跟对象密切相关的，它不能被重用

适合场景：

1. 如果对象需要根据自身当前状态进行不同行为，同时状态的数量非常多且与状态相关的代码会频繁变更时。
2. 如果某个类根据成员变量的当前值改变自身行为，从而需要使用大量的条件语句时。
3. 当相似状态和基于状态转换中存在许多重复代码时

8、策略模式（Strategy）

它能让你定义一系列算法， 并将每种算法分别放入独立的类中， 以使算法的对象能够相互替换

即将一组算法封装成一系列对象。通过调用这些对象可以灵活的改变程序的功能

策略模式更侧重于根据具体情况选择策略，并不涉及切换。策略模式做的都是同一件事。

策略模式封装算法或策略，通过从Context中分离出策略或算法，我们可以重用它们。

适合场景：

1. 想使用对象中各种不同的算法变体，并希望在运行时切换算法时。
2. 如果算法在上下文的逻辑中不是特别重要，使用该模式能将类的业务逻辑与算法实现细节隔离开来。
3. 当类中使用了复杂条件运算符如：if else，以在同一算法的不同变体中切换时。

可以用策略模式和工厂模式优化程序中过多的if-else

9、模版模式（template）

在超类中定义了一个算法的框架， 允许子类在不修改结构的情况下重写算法的特定步骤。

即让子类可以重写方法的一部分，而不是整个重写，你可以控制子类需要重写那些操作。

适合场景：

1. 只希望客户端扩展某个特定的算法步骤，而不是整个算法或其结构时。
2. 当多个类的算法除了一些细微不同之外几乎完全一样时。

用例：

1. InputStream类的skip或read方法
2. 我们可以做一个抽象类，某个方法需要子类来实现差异化

10、访问者模式（Visitor）

提供一个方便的可维护的方式来操作一组对象。它使得你在不改变操作的对象前提下，可以修改或者扩展对象的行为。

它能将算法与其所作用的对象隔离开来。虽然可以在不改变原有类结构的基础上不断添加新的功能。但是缺点是破坏了封装性

适合场景：

1. 需要对一个复杂的对象结构（如对象树）中所有的元素执行某些操作时。
2. 可使用此模式来清理辅助行为的业务逻辑
3. 当某个行为仅在类层次结构中的一些类中有意义，在其他类中没意义是。

11、空对象模式（Empty）

它允许抽象空对象的处理。

用例：

1. Collections类的emptyList()
2. Collections类的emptyMap()
3. Collections类的emptySet()

12、解释器模式（Interpreter）

通常描述为该语言定义语法并使用该语法来解释该格式的语句

用例：

1. Pattern类
2. Normalizer类
3. Format类

更多更详细设计模式请参考：常用设计模式有哪些？