策略模式
使用场景：
1.针对同一类型问题的多种处理方式，仅仅是具体行为有差别时
2.需要安全的封装多种同一类型的操作时
3.出现同一抽象类有多个子类，而又需要使用if-else或者switch-case来选择具体子类时
策略模式主要用来分离算法，在相同的行为抽象下有不同的具体实现策略。这个模式很好的演示了开闭原则，也就是定义抽象，注入不同的实现，从而达到很好的扩展性。
优点：
结构清晰明了，使用简单直观
耦合度相对而言较低，扩展方便
操作封装也更为彻底，数据更为安全。
缺点： 随着策略的增加，子类也会变得繁多。
状态模式
使用场景：
1.一个对象的行为取决于他的状态，并且他必须在运行时根绝状态改变他的行为
2.代码中包含大量域对象状态有关的条件语句。例如，一个操作中包含有庞大的多分支语句（if-else或者switch-case）,且这些分支依赖于该对象的状态。
优点
State模式将所有与一个特定的和状态相关的行为都放入一个状态对象中，提供了一个更好的方法来组织与特定状态相关的代码，将繁琐的状态判断转化成结构清晰的转台类族，在避免代码膨胀的同时也保证了可扩展性与可维护性。
缺点：
状态模式的使用必然会增加系统类型和对象的个数。
责任链模式
多个对象可以处理同一个请求，但具体由哪个对象处理则在运行时动态决定。
在请求处理者不明确的情况下向多个对象中的一个提交一个请求。
需要动态指定一组对象处理请求
有点：可以对请求者和处理者关系解耦，提高代码灵活性
缺点：对链中请求处理者的遍历，如果是处理者太多那么遍历必定会影响性能，特别是在一些递归调用中，要慎用。
解释器模式
使用场景：
1.如果某个简单的语言需要解释执行而且可以将改语言中的语句表示为一个抽象语法树时可以考虑使用解释器模式。
2.在某些特定的领域出现不断重复的问题时，可以将该领域的问题转化为一种语法规则下的语句，然后构建解释器来解释该语句。
优点：灵活的扩展性。当我们想对文法规则进行扩展延伸时，只需要增加相应的非终结解释器，并在构建抽象语法树时，使用到新增的解释器对象进行具体的解释即可。
缺点：对于每一条文法都可以对应至少一个解释器，其会生成大量的类，导致后期维护困难；同时对于过于复杂的文法，构建其抽象语法树会显得异常繁琐，甚至有可能会出现需要构建多棵抽象语法树的情况，因此，对于复杂的文法并不推荐使用解释器模式。
命令模式
观察者模式
observe obserable
BroadcaseReceiver EventBus 等都是观察者模式
有点：
1、观察者与被观察者之间是抽象耦合，应对业务变化
2、增强系统灵活性、可扩展性
缺点：在应用观察者模式时需要考虑一下开发效率和运行效率问题，程序中包括一个被观察者、多个观察者、开发和调试等内容会比较复杂，而且在Java中消息的通知默认是顺序执行的，一个观察者卡顿会影响整体的执行效率，在这种情况下一般考虑采用异步的形式。
备忘录模式
使用场景：
需要保存一个对象在某一个时刻的状态或部分状态。
如果用一个接口来让其他对象得到这些状态，将会暴露对象的实现细节并破坏对象的封装性，一个对象不希望外界直接访问其内状态，通过间接对象可以间接访问其内部状态。
优点：
给用户提供了一种可以恢复状态的机制，可以使用户比较方便的回到某个历史的状态。
实现了信息的封装，使得用户不需要关心状态的保存细节。
缺点：消耗资源，如果类的成员变量过多，势必会占用比较大的资源，而且每一次的保存都会消耗一定的内存。
迭代器模式
使用场景：遍历一个容器对象时
优点：支持以不同的方式去遍历一个容器对象，也可以有多个遍历，弱化了容器类与遍历算法之间的关系。
缺点：类文件的增加。
模版方法模式
使用场景：
1.多个子类有公有的方法，并且逻辑基本相同
2.重要复杂的算法，可以把核心算法设计为模板方法，周边的相关细节功能则由各个子类实现
3.重构时，模板方法模式是一个经常使用的模式，把相同的代码抽取到父类中，然后通过钩子函数约束其行为。
final方法 防止算法框架被覆盖
优点：
封装不变部分，扩展可变部分。提取公共部分代码，便于维护。
缺点：模板方法会带来代码阅读的难度，会让用户觉得难以理解。
访问者模式
使用场景：
对象结构比较稳定，但经常需要在此对象结构上定义新的操作。
需要对一个对象结构中的对象进行很多不同的并且不相关的操作，而需要避免这些操作污染这些对象的类，也不希望在增加新操作时修改这些类。
优点：
各角色职责分离，符合单一职责原则。具有优秀的扩展性。使得数据结构和作用于结构上的操作解耦，使得操作集合可以独立变化。灵活性。
缺点：
具体元素对访问者公布细节，违反了迪米特原则。具体元素变更时导致修改成本大。违反了依赖倒置原则，为了达到“区别对待”而依赖了具体类，没有依赖抽象。
中介者模式
使用场景：
当对象之间的交互操作很多且每个对象的行为操作都依赖彼此时，为防止在修改一个对象的行为时，同时涉及修改很多其他对象的行为，可采用中介者模式，来解决紧耦合问题。该模式将对象之间的多对多关系变成一对多关系，中介者对象将系统从网状结构变成以调停者为中心的星形结构，达到降低系统的复杂性，提高可扩展性的作用。
代理模式
使用场景：当无法或不想直接访问某个对象或访问某个对象存在困难时可以通过一个代理对象间接访问，为了保证客户端使用的透明性，委托对象与代理对象需要实现相同的接口。
静态代理模式 动态代理
组合模式
透明的组合模式 安全的组合模式
优点：
可以清楚的定义分层次的复杂对象，表示对象的全部或部分层次，它让高层模块忽略了层次的差异，方便对整个层次结构进行控制。
高层模块可以一致的使用一个组合结构或其中单个对象，不必关心处理的是单个对象还是整个组合结构，简化了高层模块的代码。
在组合模式中增加新的枝干构件和叶子构件都很方便，无需对现有类库进行修改，符合开闭原则。
组合模式为树形结构的面向对象实现提供了一种灵活的解决方案，同伙叶子对象和枝干对象的递归组合，可以形成复杂的树形结构，但对树形结构的控制却非常简单。
缺点：
在新增构件时不好对枝中的构件类型进行限制，不能依赖类型系统来施加这些约束，因为在大多数情况下，他们都来自于相同的抽象层。此时必须实时进行类型检查来实现，这个实现过程较为复杂。
适配器模式
系统需要使用现有的类，而此类的接口不符合系统的需要，即接口不兼容。
想要建立一个可以重复使用的类，用于与一些彼此之间没有太大关联的一些类，包括一些可能在将来引进的类一起工作
类适配器模式 对象适配器模式
装饰模式
需要透明且动态的扩展类的
装饰模式是以对客户端透明的方式扩展对象的功能，是继承关系的一个替代方案；而代理模式则是给一个对象提供一个代理对象，并由代理对象来控制对原有对象的引用。装饰模式应该为所装饰的对象增强功能；代理模式对代理的对象施加控制，但不对对象本身的功能进行增强。
享元模式
系统中存在大量的相似对象。 细粒度的对象都具备较接近的外部状态，而且内部状态与环境无关，也就是说对象没有特定身份。 需要缓冲池的场景。
