1.单例模式
确保某一个类只有一个实例，而且自行实例化并向整个系统提供这个实例。
使用场景：
● 要求生成唯一序列号的环境；
● 在整个项目中需要一个共享访问点或共享数据，例如一个Web页面上的计数器，可以不用把每次刷新都记录到数据库中，使用单例模式保持计数器的值，并确保是线程安全的；
● 创建一个对象需要消耗的资源过多，如要访问IO和数据库等资源；
● 需要定义大量的静态常量和静态方法（如工具类）的环境，可以采用单例模式（当然，也可以直接声明为static的方式）。
2.工厂模式
定义一个用于创建对象的接口，让子类决定实例化哪一个类。工厂方法使一个类的实例化延迟到其子类。
简单工厂模式：
一个模块仅需要一个工厂类，没有必要把它产生出来，使用静态的方法
多个工厂类：
每个人种（具体的产品类）都对应了一个创建者，每个创建者独立负责创建对应的产品对象，非常符合单一职责原则
代替单例模式：
单例模式的核心要求就是在内存中只有一个对象，通过工厂方法模式也可以只在内存中生产一个对象
延迟初始化：
ProductFactory负责产品类对象的创建工作，并且通过prMap变量产生一个缓存，对需要再次被重用的对象保留
使用场景：jdbc连接数据库，硬件访问，降低对象的产生和销毁
3.抽象工厂模式
为创建一组相关或相互依赖的对象提供一个接口，而且无须指定它们的具体类。
使用场景：
● 多个子类有公有的方法，并且逻辑基本相同时。
● 重要、复杂的算法，可以把核心算法设计为模板方法，周边的相关细节功能则由各个子类实现。
● 重构时，模板方法模式是一个经常使用的模式，把相同的代码抽取到父类中，然后通过钩子函数（见“模板方法模式的扩展”）约束其行为。
5.建造者模式
将一个复杂对象的构建与它的表示分离，使得同样的构建过程可以创建不同的表示。
使用场景：
● 相同的方法，不同的执行顺序，产生不同的事件结果时，可以采用建造者模式。
● 多个部件或零件，都可以装配到一个对象中，但是产生的运行结果又不相同时，则可以使用该模式。
● 产品类非常复杂，或者产品类中的调用顺序不同产生了不同的效能，这个时候使用建造者模式非常合适。
建造者模式与工厂模式的不同：
建造者模式最主要的功能是基本方法的调用顺序安排，这些基本方法已经实现了，顺序不同产生的对象也不同；
工厂方法则重点是创建，创建零件是它的主要职责，组装顺序则不是它关心的。
6.代理模式
为其他对象提供一种代理以控制对这个对象的访问。
普通代理和强制代理：
普通代理就是我们要知道代理的存在，也就是类似的GamePlayerProxy这个类的存在，然后才能访问；
强制代理则是调用者直接调用真实角色，而不用关心代理是否存在，其代理的产生是由真实角色决定的。
普通代理：
在该模式下，调用者只知代理而不用知道真实的角色是谁，屏蔽了真实角色的变更对高层模块的影响，真实的主题角色想怎么修改就怎么修改，对高层次的模块没有任何的影响，只要你实现了接口所对应的方法，该模式非常适合对扩展性要求较高的场合。
强制代理：
强制代理的概念就是要从真实角色查找到代理角色，不允许直接访问真实角色。高层模块只要调用getProxy就可以访问真实角色的所有方法，它根本就不需要产生一个代理出来，代理的管理已经由真实角色自己完成。
动态代理：
根据被代理的接口生成所有的方法，也就是说给定一个接口，动态代理会宣称“我已经实现该接口下的所有方法了”。
两条独立发展的线路。动态代理实现代理的职责，业务逻辑Subject实现相关的逻辑功能，两者之间没有必然的相互耦合的关系。通知Advice从另一个切面切入，最终在高层模块也就是Client进行耦合，完成逻辑的封装任务。
动态代理调用过程示意图：
动态代理的意图：横切面编程，在不改变我们已有代码结构的情况下增强或控制对象的行为。
首要条件：被代理的类必须要实现一个接口。
7.原型模式
用原型实例指定创建对象的种类，并且通过拷贝这些原型创建新的对象。
使用原型模式的优点：
● 性能优良
原型模式是在内存二进制流的拷贝，要比直接new一个对象性能好很多，特别是要在一个循环体内产生大量的对象时，原型模式可以更好地体现其优点。
● 逃避构造函数的约束
这既是它的优点也是缺点，直接在内存中拷贝，构造函数是不会执行的（参见13.4节）。
使用场景：
● 资源优化场景
类初始化需要消化非常多的资源，这个资源包括数据、硬件资源等。
● 性能和安全要求的场景
通过new产生一个对象需要非常繁琐的数据准备或访问权限，则可以使用原型模式。
● 一个对象多个修改者的场景
一个对象需要提供给其他对象访问，而且各个调用者可能都需要修改其值时，可以考虑使用原型模式拷贝多个对象供调用者使用。
浅拷贝和深拷贝：
浅拷贝：Object类提供的方法clone只是拷贝本对象，其对象内部的数组、引用对象等都不拷贝，还是指向原生对象的内部元素地址，这种拷贝就叫做浅拷贝，其他的原始类型比如int、long、char、string（当做是原始类型）等都会被拷贝。
注意： 使用原型模式时，引用的成员变量必须满足两个条件才不会被拷贝：一是类的成员变量，而不是方法内变量；二是必须是一个可变的引用对象，而不是一个原始类型或不可变对象。
深拷贝：对私有的类变量进行独立的拷贝
如：thing.arrayList = (ArrayList<String>)this.arrayList.clone();
8.中介者模式
用一个中介对象封装一系列的对象交互，中介者使各对象不需要显示地相互作用，从而使其耦合松散，而且可以独立地改变它们之间的交互。
使用场景：
中介者模式适用于多个对象之间紧密耦合的情况，紧密耦合的标准是：在类图中出现了蜘蛛网状结构，即每个类都与其他的类有直接的联系。
9.命令模式
将一个请求封装成一个对象，从而让你使用不同的请求把客户端参数化，对请求排队或者记录请求日志，可以提供命令的撤销和恢复功能。
使用场景：
认为是命令的地方就可以采用命令模式，例如，在GUI开发中，一个按钮的点击是一个命令，可以采用命令模式；模拟DOS命令的时候，当然也要采用命令模式；触发－反馈机制的处理等
10.责任链模式
使多个对象都有机会处理请求，从而避免了请求的发送者和接受者之间的耦合关系。将这些对象连成一条链，并沿着这条链传递该请求，直到有对象处理它为止。
抽象的处理者实现三个职责：
一是定义一个请求的处理方法handleMessage，唯一对外开放的方法；
二是定义一个链的编排方法setNext，设置下一个处理者；
三是定义了具体的请求者必须实现的两个方法：定义自己能够处理的级别getHandlerLevel和具体的处理任务echo。
注意事项：
链中节点数量需要控制，避免出现超长链的情况，一般的做法是在Handler中设置一个最大节点数量，在setNext方法中判断是否已经是超过其阈值，超过则不允许该链建立，避免无意识地破坏系统性能。
11.装饰模式
动态地给一个对象添加一些额外的职责。就增加功能来说，装饰模式相比生成子类更为灵活。
使用场景：
● 需要扩展一个类的功能，或给一个类增加附加功能。
● 需要动态地给一个对象增加功能，这些功能可以再动态地撤销。
● 需要为一批的兄弟类进行改装或加装功能，当然是首选装饰模式。
12.策略模式
定义一组算法，将每个算法都封装起来，并且使它们之间可以互换。
使用场景：
● 多个类只有在算法或行为上稍有不同的场景。
● 算法需要自由切换的场景。
● 需要屏蔽算法规则的场景。
注意事项：具体策略数量超过4个，则需要考虑使用混合模式
定义：
● 它是一个枚举。
● 它是一个浓缩了的策略模式的枚举。
注意：
受枚举类型的限制，每个枚举项都是public、final、static的，扩展性受到了一定的约束，因此在系统开发中，策略枚举一般担当不经常发生变化的角色。
致命缺陷：
所有的策略都需要暴露出去，由客户端决定使用哪一个策略。
13.适配器模式
将一个类的接口变换成客户端所期待的另一种接口，从而使原本因接口不匹配而无法在一起工作的两个类能够在一起工作。
使用场景：
你有动机修改一个已经投产中的接口时，适配器模式可能是最适合你的模式。比如系统扩展了，需要使用一个已有或新建立的类，但这个类又不符合系统的接口，怎么办？使用适配器模式，这也是我们例子中提到的。
注意事项：
详细设计阶段不要考虑使用适配器模式，使用主要场景为扩展应用中。
对象适配器：
对象适配器和类适配器的区别：
类适配器是类间继承，对象适配器是对象的合成关系，也可以说是类的关联关系，这是两者的根本区别。（实际项目中对象适配器使用到的场景相对比较多）。
14.迭代器模式
它提供一种方法访问一个容器对象中各个元素，而又不需暴露该对象的内部细节。
ps：迭代器模式已经被淘汰，java中已经把迭代器运用到各个聚集类（collection）中了，使用java自带的迭代器就已经满足我们的需求了。
15.组合模式
将对象组合成树形结构以表示“部分-整体”的层次结构，使得用户对单个对象和组合对象的使用具有一致性。
使用场景：
● 维护和展示部分-整体关系的场景，如树形菜单、文件和文件夹管理。
● 从一个整体中能够独立出部分模块或功能的场景。
注意：
只要是树形结构，就考虑使用组合模式。
16.观察者模式
定义对象间一种一对多的依赖关系，使得每当一个对象改变状态，则所有依赖于它的对象都会得到通知并被自动更新。
使用场景：
● 关联行为场景。需要注意的是，关联行为是可拆分的，而不是“组合”关系。
● 事件多级触发场景。
● 跨系统的消息交换场景，如消息队列的处理机制。
注意：
● 广播链的问题
在一个观察者模式中最多出现一个对象既是观察者也是被观察者，也就是说消息最多转发一次（传递两次）。
● 异步处理问题
观察者比较多，而且处理时间比较长，采用异步处理来考虑线程安全和队列的问题。
17.门面模式
要求一个子系统的外部与其内部的通信必须通过一个统一的对象进行。门面模式提供一个高层次的接口，使得子系统更易于使用。
使用场景：
● 为一个复杂的模块或子系统提供一个供外界访问的接口
● 子系统相对独立——外界对子系统的访问只要黑箱操作即可
● 预防低水平人员带来的风险扩散
注意：
●一个子系统可以有多个门面
●门面不参与子系统内的业务逻辑
18.备忘录模式
在不破坏封装性的前提下，捕获一个对象的内部状态，并在该对象之外保存这个状态。这样以后就可将该对象恢复到原先保存的状态。
使用场景：
● 需要保存和恢复数据的相关状态场景。
● 提供一个可回滚（rollback）的操作。
● 需要监控的副本场景中。
● 数据库连接的事务管理就是用的备忘录模式。
注意：
●备忘录的生命期
●备忘录的性能
不要在频繁建立备份的场景中使用备忘录模式（比如一个for循环中）。
clone方式备忘录：
● 发起人角色融合了发起人角色和备忘录角色，具有双重功效
多状态的备忘录模式
● 增加了一个BeanUtils类，其中backupProp是把发起人的所有属性值转换到HashMap中，方便备忘录角色存储。restoreProp方法则是把HashMap中的值返回到发起人角色中。
19.访问者模式
封装一些作用于某种数据结构中的各元素的操作，它可以在不改变数据结构的前提下定义作用于这些元素的新的操作。
使用场景：
● 一个对象结构包含很多类对象，它们有不同的接口，而你想对这些对象实施一些依赖于其具体类的操作，也就说是用迭代器模式已经不能胜任的情景。
● 需要对一个对象结构中的对象进行很多不同并且不相关的操作，而你想避免让这些操作“污染”这些对象的类。
20.状态模式
当一个对象内在状态改变时允许其改变行为，这个对象看起来像改变了其类。
使用场景：
● 行为随状态改变而改变的场景
这也是状态模式的根本出发点，例如权限设计，人员的状态不同即使执行相同的行为结果也会不同，在这种情况下需要考虑使用状态模式。
● 条件、分支判断语句的替代者
注意：
状态模式适用于当某个对象在它的状态发生改变时，它的行为也随着发生比较大的变化，也就是说在行为受状态约束的情况下可以使用状态模式，而且使用时对象的状态最好不要超过5个。
21.解释器模式
给定一门语言，定义它的文法的一种表示，并定义一个解释器，该解释器使用该表示来解释语言中的句子。
使用场景：
● 重复发生的问题可以使用解释器模式
● 一个简单语法需要解释的场景
22.享元模式
使用共享对象可有效地支持大量的细粒度的对象。
使用场景：
● 系统中存在大量的相似对象。
● 细粒度的对象都具备较接近的外部状态，而且内部状态与环境无关，也就是说对象没有特定身份。
● 需要缓冲池的场景。
注意：
● 享元模式是线程不安全的，只有依靠经验，在需要的地方考虑一下线程安全，在大部分场景下不用考虑。对象池中的享元对象尽量多，多到足够满足为止。
● 性能安全：外部状态最好以java的基本类型作为标志，如String，int，可以提高效率。
23.桥梁模式
将抽象和实现解耦，使得两者可以独立地变化。
使用场景：
● 不希望或不适用使用继承的场景
● 接口或抽象类不稳定的场景
● 重用性要求较高的场景
注意：
发现类的继承有N层时，可以考虑使用桥梁模式。桥梁模式主要考虑如何拆分抽象和实现。