写在最前面

设计模式其实并没有想象中的高大上，不必死记硬背，重点是结合自己的编码实践，思考背后的设计原则(开闭原则、单一职责原则等)。

设计模式在使用的时候，不是死板的一个一个模式套用，更多的是多个设计模式混合起来。最终的目的是写出解耦的、易扩展的、可读性好的代码。

设计模式说白了就是为某种代码的写法，提供一种通用语言，降低程序员沟通之间的成本。

不要落入设计模式的陷阱

面对不确定的功能和流程，以后可能要经常改的业务代码，不要过早引入设计模式。
业务还没有稳定下来，过早抽象，反而会影响到开发进度过早背上技术债务。

这种情况下又要支持不同环境下的不同特性，可以考虑用其他方式实现，比如组合模式+mock插桩。

创造型模式(5)

工厂方法

定义一个创建对象的接口，让子类决定实例化那个类。

抽象工厂

创建相关或依赖对象的家族，而无需明确指定具体类。

单例模式

某个类只能有一个实例，提供一个全局的访问点。

建造者模式

封装一个复杂对象的构建过程，并可以按步骤构造。

原型模式

通过复制现有的实例来创建新的实例。

结构型模式(7)

适配器模式

将一个类的方法接口转换成客户希望的另外一个接口，使接口不兼容的对象能够相互合作。

代理模式

代理是为了包装一个类，对相关操作进行二次转发或者进行一些管控。

桥接模式

将抽象与其实现分离，以便两者可以独立变化。
可将一个大类或一系列紧密相关的类拆分为抽象和实现两个独立的层次结构，从而能在开发时分别使用。

组合模式

将对象组合成树结构以表示部分整体层次结构。允许客户端统一处理单个对象和对象的组合。

装饰者模式

允许你通过将对象放入包含行为的特殊封装对象中来为原对象绑定新的行为。

门面模式

为子系统中的一组接口提供统一的接口。定义使子系统更易于使用的高级接口。

享元模式

通过共享技术来有效的支持大量细粒度的对象。
当我们已经存在一些内容的时候，可以通过缓存复用，而不是重新创建，减少开销。

行为模式(11)

责任链模式

通过为多个对象提供处理请求的机会，避免将请求的发送方与其接收方耦合。链接接收对象并沿链传递请求，直到对象处理它。

Avoid coupling the sender of a request to its receiver by giving more than one object a chance to handle the request. Chain the receiving objects and pass the request along the chain until an object handles it.

命令模式

它可将请求转换为一个包含与请求相关的所有信息的独立对象。该转换让你能根据不同的请求将方法参数化、延迟请求执行或将其放入队列中，且能实现可撤销操作。

迭代器模式

一种遍历访问聚合对象中各个元素的方法，不暴露该对象的内部结构。

中介者模式

亦称：调解人、控制器、Intermediary、Controller、Mediator

定义一个封装一组对象如何交互的对象。通过防止对象显式相互引用来促进松耦合，并允许你独立改变它们的交互。

中介者模式建议你停止组件之间的直接交流并使其相互独立。这些组件必须调用特殊的中介者对象，通过中介者对象重定向调用行为，以间接的方式进行合作。最终，组件仅依赖于一个中介者类，无需与多个其他组件相耦合。

客户端不直接依赖各个组件，而是引入一个中介，将依赖关系下沉到中介上面。客户端只依赖中介，从而降低耦合。

一段时间后，中介者可能会演化成为上帝对象。

备忘录模式

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

观察者模式

亦称：事件订阅者、监听者、Event-Subscriber、Listener、Observer
监听回调，消息订阅。
由发布者和订阅者两大部分组成。

状态模式

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

将状态和行为封装到一起去，这样一来，可以在独立于其他状态的情况下添加新状态或修改已有状态，从而减少维护成本。

策略模式

定义一系列算法，封装每个算法，并使它们可互换。

模板模式

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

就是通过继承，重写父类代码。

访问者模式

访问者（Visitor）模式的定义： 将作用于某种数据结构中的各元素的操作分离出来封装成独立的类，使其在不改变数据结构的前提下可以添加作用于这些元素的新的操作，为数据结构中的每个元素提供多种访问方式。

对数据的操作与数据结构进行分离。

https://refactoringguru.cn/design-patterns/visitor

解释器模式

定义：给定一个语言，定义它的文法的一种表示，并定义一个解释器，这个解释器使用该表示来解释语言中的句子。

解释器模式更加小众，只在一些特定的领域会被用到，比如编译器、规则引擎、正则表达式、DSL。

解释器模式包含以下主要角色。

抽象表达式（Abstract Expression）角色：定义解释器的接口，约定解释器的解释操作，主要包含解释方法 interpret()。
终结符表达式（Terminal Expression）角色：是抽象表达式的子类，用来实现文法中与终结符相关的操作，文法中的每一个终结符都有一个具体终结表达式与之相对应。
非终结符表达式（Nonterminal Expression）角色：也是抽象表达式的子类，用来实现文法中与非终结符相关的操作，文法中的每条规则都对应于一个非终结符表达式。
环境（Context）角色：通常包含各个解释器需要的数据或是公共的功能，一般用来传递被所有解释器共享的数据，后面的解释器可以从这里获取这些值。
客户端（Client）：主要任务是将需要分析的句子或表达式转换成使用解释器对象描述的抽象语法树，然后调用解释器的解释方法，当然也可以通过环境角色间接访问解释器的解释方法。

解释器模式参考资料

https://blog.csdn.net/kimichen123/article/details/120145786

极客时间设计模式之美 72丨解释器模式

参考

不好的资料

《Java设计模式与实践》
豆瓣6.1 ，容易被书名迷惑。实际上这本书讲了很多设计模式之外的东西，没有重点关注设计模式。
同时翻译也是个问题，不推荐。

Chenaa's Notes

GoF 23种经典设计模式