设计模式

单例模式

确保某一个类只有一个实例，而且自行实例化并向整个系统提供这个实例。
可以实现一个限制对象数量的多例。

工厂方法模式

定义一个用于创建对象的接口，让子类决定实例化哪一个类。工厂方法使一个类的实例化延迟到其子类。
1、可以缩小为简单工厂模式
2、可以升级为多个工厂类
3、可以替代单例模式
4、延迟初始化

抽象工厂模式

为创建一组相关或相互依赖的对象提供一个接口，而且无须指定它们的具体类。

模版方法模式

定义一个操作中的算法的框架，将一些步骤延迟到子类中。使得子类可以不改变一个算法的结构即可重定义该算法的某些特定步骤。
基本方法，由子类实现，一般为protected
模板方法，完成固定的逻辑，一般都加上final
钩子方法，影响模板方法的执行结果，例如，根据方法控制某个流程是否执行

建造者模式

将一个复杂对象的构建与它的表示分离，使得同样的构建过程可以创建不同的表示。
使用场景：（关注零件类型和装配工艺）
相同的方法，不同的执行顺序，产生不同的事件结果时。
多个部件或零件，都可以装配到一个对象中，但是产生的运行结果又不相同时。
产品类非常复杂，或者产品类中的调用顺序不同产生了不同的效能。
在对象创建过程中会使用到系统中的一些其他对象，这些对象在产品对象的创建过程中不易得到时。

代理模式

为其他对象提供一种代理以控制对这个对象的访问。
Spring AOP就是一个典型的动态代理。
普通代理：需要知道代理的存在，才能访问
强制代理：调用者直接调用真实角色，不用关心代理是否存在
动态代理是在实现阶段不用关心代理谁，而在运行阶段才指定代理哪一个对象。
核心接口InvocationHandler
JDK实现动态代理的首要条件：被代理类必须实现一个接口（CGLIB不需要实现接口）
Spring AOP：没有实现任何接口时使用CGLIB，实现了接口则使用JDK动态代理

原型模式

用原型实例指定创建对象的种类，并且通过拷贝这些原型创建新的对象。
简单来说就是不通过new来产生一个对象，而是通过对象复制来实现。
原型模式是在内存二进制流的拷贝，比new的性能好很多。不执行构造函数。
浅拷贝、深拷贝问题
clone和final冲突问题，final不允许重新赋值

中介者模式

用一个中介对象封装一系列的对象交互，中介者使各对象不需要显式的相互作用，从而使其耦合松散，而且可以独立的改变它们之间的交互。
改变对象本身的状态，处理自己的行为，称为自发行为，跟其他“同事”类或中介者没有任何依赖。
必须依赖中介者才能完成的行为，叫做依赖方法。
当类间的调用关系是网状时，可以使用中介者模式。
MVC框架中的Controller就是一个中介者。

命令模式

命令模式是一个高内聚的模式，将一个请求封装成一个对象，从而让你使用不同的请求把客户端参数化，对请求排队或者记录请求日志，可以提供命令的撤销和恢复功能。

责任链模式

使每个对象都有机会处理请求，从而避免了请求的发送者和接受者之间的耦合关系。将这些对象连成一条链，并沿着这条链传递该请求，直到有对象处理它为止。

装饰模式

动态的给一个对象添加一些额外的职责。就增加功能来说，装饰模式相比生成子类更为灵活。

策略模式

定义一组算法，将每个算法都封装起来，并且使它们之间可以互换。
策略模式的封装角色和被装备的策略类不是同一个接口。同一个接口的是代理模式。
扩展：策略枚举

适配器模式

将一个类的接口变换成客户端锁期待的另一种接口，从而使原本因接口不匹配而无法在一起工作的两个类能够在一起工作。简单来说就是远程对象转换为本地对象。
一个对象不存储实体状态以及对象之间的关系，这个对象就是贫血对象，反之为充血对象。

迭代器模式

目前已经是一个没落的模式。
它提供一种方法访问一个容器对象中各个元素，而又不需暴露该对象的内部细节。

组合模式（部分-整体模式）

将对象组合成树形结构以表示“部分-整体”的层次结构，使得用户对单个对象和组合对象的使用具有一致性。

观察者模式（发布订阅模式）

定义对象间一种一对多的依赖关系，使得每当一个对象改变状态，则所有依赖于它的对象都会得到通知并被自动更新。
缺点：
消息的通知默认是顺序执行的，一个观察者卡壳，会影响整体的执行效率，一般考虑异步的方式。
观察者可以有双重身份，既是观察者也是被观察者。广播链。
广播链在传播的过程中消息是随时更改的，由两个节点协商。
责任链模式在消息传递过程中基本上保持消息不可变。如果要改变，也只是在原有消息上修正。
Java提供了API，Observer/Observable

门面模式

要求一个子系统的外部与其内部的通信必须通过一个统一的对象进行（不允许有其它对象能访问子系统）。门面模式提供一个高层次的接口，使得子系统更易于使用。
优点：
1、减少系统的相互依赖
2、提高了灵活性、安全性
使用场景：
1、为一个复杂的模块或子系统提供一个供外界访问的接口
2、子系统相对独立，外界对子系统的访问只要黑箱操作即可
3、预防低水平开发人员带来的风险扩散

备忘录模式

在不破坏封装性的前提下，捕获一个对象的内部状态，并在改对象之外保存这个状态。这样以后就可将该对象恢复到原先保存的状态。
使用场景：
1、需要保存和回复数据的相关状态场景
2、提供一个可回滚的操作
3、需要监控的副本场景
可以和克隆模式联合使用
还需要注意多状态的备忘录模式

访问者模式

封装一些作用于某种数据结构中的各元素的操作，它可以在不改变数据结构的前提下定义作用于这些元素的新的操作。
重载在编译器期就决定了要调用哪个方法，这是静态绑定。
重写则是由其实际类型决定，这是动态绑定。

状态模式

当一个对象内在状态改变时允许其改变行为，这个对象看起来像改变了其类。
状态模式中的3个角色：
1、State，抽象状态角色
2、ConcreteState，具体状态角色，有多个
3、Context，环境角色，单个
环境角色的不成文约束：

• 把状态对象声明为静态常量，有几个状态对象就声明几个静态常量。
• 环境角色具有状态抽象角色定义的所有行为，具体执行使用委托方式。
  具体状态角色并不是指“在某状态下”，而是指“转换到某个状态”

解释器模式

给定一门语言，定义它的方法的一种表示，并定义一个解释器，该解释器使用该表死后来解释语言中的句子。
数据分析工具、报表设计工具、科学计算工具等，一般都有开源工具包

享元模式

享元模式是池技术的重要实现方式。使用共享对象可有效地支持大量的细粒度的对象。
使用场景：

• 系统中存在大量的相似对象。
• 细粒度的对象都具备较接近的外部状态，而且内部状态与环境无关，也就是说对象没有特定身份。
• 需要缓冲池的场景
  线程安全性问题，其中一个解决方案：对象池中的享元对象尽量多，多懂啊足够满足业务为止。
  虽然可以使用享元模式实现对象池，但是这两者还是有比较大的差异。对象池着重在对象的复用上，池中的每个对象是可替换的，从同一个池中获得A对象和B对象对客户端来说是完全相同的，它主要解决复用，而享元模式主要解决对象的共享问题，如何建立多个可共享的细粒度对象则是关注的重点。

桥梁模式

将抽象和实现解耦，使得两者可以独立地变化。