寓教于乐。教己助人

组合模式解耦了客户程序与复杂元素内部结构，从而使客户程序可以像处理简单元素一样来处理复杂元素。如果你想要创建层次结构，并可以在其中以相同的方式对待所有元素，那么组合模式就是最理想的选择。本章使用了一个文件系统的例子来举例说明了组合模式的用途。在这个例子中，文件和目录都执行相同的接口，这是组合模式的关键。通过执行相同的接口，你就可以用相同的方式对待文件和目录，从而实现将文件或者目录储存为目录的子级元素。

访问者模式（Visitor Pattern）是GoF提出的23种设计模式中的一种，属于行为模式。据《大话设计模式》中说算是最复杂也是最难以理解的一种模式了。从定义可以看出结构对象是使用访问者模式必备条件，而且这个结构对象必须存在遍历自身各个对象的方法。这便类似于Java语言当中的collection概念了。

解释器模式为某个语言定义它的语法表示，并定义一个解释器用来处理这个语法。语言：不仅仅指平时说的中、英、日、法等各种语言。从广义上来讲，只要是能承载信息的载体，我们都可以称之为“语言”，比如，古代的结绳记事、盲文、哑语、摩斯密码等。一些应用提供了内建(Build-In)的脚本或者宏语言来让用户可以定义他们能够在系统中进行的操作。解释器模式的目的就是使用一个解释器为用户提供一个一门定义语言的语法表示的解释器，然后通过这个解释器来解释语言中的句子。

迭代器模式（Iterator Pattern）是 Java 和 .Net 编程环境中非常常用的设计模式。这种模式用于顺序访问集合对象的元素，不需要知道集合对象的底层表示。迭代器模式就是分离了集合对象的遍历行为，抽象出一个迭代器类来负责，这样既可以做到不暴露集合的内部结构，又可让外部代码透明地访问集合内部的数据。

顾名思义，责任链模式（Chain of Responsibility Pattern）为请求创建了一个接收者对象的链。这种模式给予请求的类型，对请求的发送者和接收者进行解耦。这种类型的设计模式属于行为型模式。在这种模式中，通常每个接收者都包含对另一个接收者的引用。如果一个对象不能处理该请求，那么它会把相同的请求传给下一个接收者，依此类推。

在软件系统中，“行为请求者”与“行为实现者”通常呈现一种“紧耦合”。但在某些场合，比如要对行为进行“记录、撤销/重做、事务”等处理，这种无法抵御变化的紧耦合是不合适的。在这种情况下，如何将“行为请求者”与“行为实现者”解耦？将一组行为抽象为对象，实现二者之间的松耦合。这就是命令模式（Command Pattern）

备忘录模式能帮我们在不破坏封装性的前提下，捕获一个对象的内部状态，并在该对象之外保存这个状态。备忘录模式使得对象的状态管理更加灵活。它允许对象在不暴露其内部结构的情况下进行状态的保存和恢复。这有助于实现撤销和重做功能，以及历史记录和快照功能。然而，使用备忘录模式可能会增加一些内存开销，特别是如果需要存储大量的状态历史。总之，备忘录模式在需要记录和恢复对象状态的情况下是一个有用的设计模式。它可以帮助保持代码的清晰性和可维护性，同时提供强大的状态管理功能。

中介者模式（Mediator Pattern）是用来降低多个对象和类之间的通信复杂性。这种模式提供了一个中介类，该类通常处理不同类之间的通信，并支持松耦合，使代码易于维护。中介者模式属于行为型模式。

观察者模式可以帮我们当一个对象被修改时， 自动通知依赖它的对象。观察者模式属于行为型模式。观察者模式是一种行为型设计模式，它定义了一种一对多的依赖关系，当一个对象的状态发生改变时，其所有依赖者都会收到通知并自动更新。当对象间存在一对多关系时，则使用观察者模式（Observer Pattern）。

状态模式能让我们的状态各自维护各自的逻辑和变化方向。在行为受状态约束的时候使用状态模式，而且状态不超过 5 个。状态过多，复杂度越高。

通过使用策略模式，可以帮助我们在运行时根据需要选择不同的算法，而不需要修改客户端代码。策略模式定义了一系列算法或策略，并将每个算法封装在独立的类中，使得它们可以互相替换。在策略模式中，我们创建表示各种策略的对象和一个行为随着策略对象改变而改变的 context 对象。策略对象改变 context 对象的执行算法。

模板方法模式可以帮我们抽象出流程的行为规范。并指定某些行为必须由子类完成。达到整个流程的完整性和过程中的可变性。**注意事项：**为防止恶意操作，一般模板方法都加上 final 关键词。

享元模式（Flyweight Pattern）主要用于减少创建对象的数量，以减少内存占用和提高性能。这种类型的设计模式属于结构型模式，它提供了减少对象数量从而改善应用所需的对象结构的方式。享元模式尝试重用现有的同类对象，如果未找到匹配的对象，则创建新对象。我们将通过创建 5 个对象来画出 20 个分布于不同位置的圆来演示这种模式。由于只有 5 种可用的颜色，所以 color 属性被用来检查现有的Circle对象。注意事项​ 1、注意划分外部状态和内部状态，否则可能会引起线程安全问题。

通过装饰模式，可以帮助我们解决扩展一个类经常使用继承方式实现，由于继承为类引入静态特征，并且随着扩展功能的增多，子类会很膨胀。动态地给一个对象添加一些额外的职责。就增加功能来说，装饰器模式相比生成子类更为灵活。

在扩展维度时，只需要要将 当前的 Abstraction 作为 Implementor 层。新增的维度作为Abstraction。去扩展即可。可以满足无线拓展的需求。对之前的维度没有任何影响。区分多维度，如果需要多维度不相关的独立扩展。那么我们就应该使用桥接模式。通过这种结构组合方式，达到无限扩展的需求。订单优惠的维度：1. 优惠卷种类2. 地区3. 渠道4. 砍一刀：人数区间5. 购物节动物的速度模型的维度：1. 科目：狗科：基准2 驴科：基准0.8。

代理模式：1、和适配器模式的区别：适配器模式主要改变所考虑对象的接口，而代理模式不能改变所代理类的接口。2、和装饰器模式的区别：装饰器模式为了增强功能，而代理模式是为了加以控制。3、 代理模式的变化形式非常多，常见的代理形式有远程代理、保护代理、虚拟代理、缓冲代理、智能引用代理等。

适配器模式请不要在开发设计阶段使用。它通常是作为已存在系统不符合我们新的接口定义时，通过适配器进行转换复用。所以我们必须满足 依赖导致和里式替换原则（即：面向高层开发）。不然后后续导致很多适配器的改造。因而，适配器模式是一个补偿模式，为了解决接口不匹配问题而存在。多说一句： 在软件架构中。适配器模型多和门面模式（外观模式）配置使用，组成防腐层。用来解藕服务间和模块间依赖问题。

一个子系统可以有多个门面当门面已经变得臃肿时子系统可以提供不同访问路径门面不参与子系统的逻辑，子系统不知道门面的存在。

建造者模式和工厂模式关注点不同。建造者关注的是零件类型和装配顺序。工厂方法模式关注的是 创建零件。通常我们使用建造者模式时，和模方法模式搭配使用。将创建零件和构造的方法通过模版固定下来。建筑器实现具体的建造逻辑。

构造函数不会执行。内部走的native方法，从内存中二进制流copy。深copy 和 浅 copy ： clone只是浅copyclone和final关键字冲突。

工厂方法模式，在项目中使用的十分频繁。我们一定要熟能生巧的使用它。工厂方法还能和其他模式搭配使用（单例模式，模版方法模式等）实现优秀的设计。抽象工厂是工厂方法针对抽象产品的升级。所以工厂模式，主要就是围绕 【工厂方法】模式为中心开展的简化或者升级【增强】。这就让我们必须理解工厂方法模式。

单例模式，多种实现。简单掌握各个的特点。心中有数即可实际开发过程中，建议使用枚举。因为大神都在用枚举做单例使用枚举实现单例的方法虽然还没有广泛采用，但是单元素的枚举类型已经成为实现Singleton的最佳方法。枚举不需要考虑线程安全，其本身enum关键字就是线程安全的。不用考虑 反射和序列化攻击。jdk做了安全策略。

1995 年，GoF（Gang of Four，四人组/四人帮）合作出版了《设计模式：可复用面向对象软件的基础》一书，共收录了 23 种设计模式，从此树立了软件设计模式领域的里程碑，人称「GoF设计模式」。描述程序在运行时复杂的流程控制，即描述多个类或对象之间怎样相互协作共同完成单个对象都无法单独完成的任务，它涉及算法与对象间职责的分配。关注点是“怎样创建对象”，特点是“将对象的创建与使用分离”，使用者不需要关注对象的创建细节，对象的创建由相关的工厂来完成。只和朋友交流，不和陌生人说话，减少代码臃肿。