模板方法模式
定义：定义了一个算法的骨架，并允许子类为一个或多个步骤提供实现；模板方法使得子类可以在不改变算法结构的情况下，重新定义算法的某些步骤
适用场景：一次性实现一个算法的不变的部分，并将可变的行为留给子类来实现；各子类中公共的行为被提取出来并集中到一个公共父类中，从而避免代码重复；目的就是让子类扩展或具体实现模板中的固定算法中的某些算法的步骤
优点：提高复用性；提高扩展性；符合开闭原则(把不变的行为写在父类中，去除子类的重复代码)
缺点：类数目增加；增加了系统实现的复杂度；继承关系自身缺点，如果父类添加新的抽象方法，所有子类都要重新改一遍

扩展：
钩子方法：提供缺省的行为，子类可以在必要时扩展

相关设计模式：
模板方法模式和工厂方法模式：工厂方法模式是模板方法模式的一种特殊实现；
模板方法模式和策略模式：两者都有封装算法；策略模式目的是使不同的算法可以相互替换，并且不影响应用层客户端的使用，策略模式可以改变算法的流程，并且算法之间可以相互替换；而模板方法模式是针对定义一个算法的流程，而将一些不太一样的具体实现步骤交给子类实现，模板方法模式不改变算法的流程


迭代器模式
定义：提供一种方法，顺序访问一个集合对象中的各个元素，而又不暴露该对象的内部表示；
适用场景：访问一个集合的内容而无需暴露它的内部表示；为遍历不同的集合结构提供一个统一的接口
优点：分离了集合对象的遍历行为；
缺点：类的个数成对增加；

相关设计模式：
迭代器模式和访问者模式：两者都是迭代的访问集合中的各个元素；访问者模式扩展开放的部分是在对象的操作上；迭代器模式扩展开放的部分是在集合对象的种类上


策略模式(一般结合工厂、单例、享元等模式使用)
定义：定义了算法家族，分别封装起来，让它们之间可以相互替换，此模式让算法的变化不会影响到使用算法的用户；可以大范围的处理掉if…else…
适用场景：系统有很多类，而它们的区别仅仅在于它们的行为不同；一个系统需要动态地在几种算法中选择一种
优点：符合开闭原则；避免使用多重条件转移语句；提高算法的保密性和安全性
缺点：客户端必须知道所有的策略类，并自行决定使用哪一个策略类；产生很多的策略类

相关设计模式：
策略模式和工厂模式：工厂模式是创建型的，工厂模式接受指令创建符合要求的具体对象；而策略模式是行为型的，接受已经创建好的对象从而实现不同的行为；
策略模式和状态模式：在使用策略模式时，客户端需要知道到底需要使用哪一个策略，某个类的对象存在多种状态，而在不同的状态下的行为有差异，而且这些状态可以发生转换，可以使用状态模式；在状态模式中，客户端不需要关心自己的状态的，这些状态会自动转换，某个系统中某个类的行为存在多种实现方式时，这种情况下使用策略模式


解释器模式(使用频率低)
定义：给定一个语言，定义它的文法的一种表示，并定义一个解释器，这个解释器使用该表示来解释语言中的句子；为了解释一个语言，而为语言创建的解释器；
适用场景：某个特定类型问题发生频率足够高(如不同的日志文件)；
优点：语法由很多类表示，容易改变及扩展此“语言”；
缺点：当语法规则数目太多时，增加了系统复杂度；

相关设计模式：
解释器模式和适配器模式：适配器模式不需要预先知道要适配的规则；解释器要把规则写好，根据规则去执行解释


观察者模式
定义：定义了对象之间的一对多依赖，让多个观察者对象同时监听某一个主体对象，当主题对象发生变化时，它的所有依赖者(观察者)都会收到通知并更新；
适用场景：关联行为场景，建立一套触发机制；
优点：观察者和被观察者之间建立一个抽象的耦合；观察者模式支持广播通信；
缺点：观察者之间有过多的细节依赖、提高时间消耗及程序复杂度；使用要得当，要避免循环调用；


备忘录模式
定义：保存一个对象的某个状态，以便在适当的时候恢复对象；“后悔药”
适用场景：保存及恢复数据相关业务场景；后悔的时候，即想恢复到之前的状态
优点：为用户提供一种可恢复机制；存档信息的封装
缺点：资源占用

相关设计模式：
备忘录模式和状态模式：在备忘录模式中用实例表示状态；在状态模式中用类表示状态；


命令模式
定义：将“请求”封装成对象，以便使用不同的请求；命令模式解决了应用程序中对象的职责以及它们之间的通信方式；
适用场景：请求的调用者和请求的接收者需要解耦，使得调用者和接收者不直接交互；需要抽象出等待执行的行为；
优点：降低耦合；容易扩展新命令或者一组命令；
缺点：命令的无限扩展会增加类的数量，提高系统实现复杂度；

相关设计模式：
命令模式和备忘录模式：两者经常结合使用，使用备忘录模式来保存命令的历史记录


中介者模式
定义：定义一个封装一组对象如何交互的对象；通过使对象明确的相互引用来促进松散耦合，并允许独立地改变它们的交互；
适用场景：系统中对象之间存在复杂的引用关系，产生的相互依赖关系结构混乱且难以理解；交互的公共行为，如果需要改变行为则可以增加新的中介者类
优点：将一对多转化成了一对一、降低程序复杂度；类之间解耦
缺点：中介者过多，导致系统复杂

相关设计模式：
中介者模式和观察者模式：两者结合使用，使用观察者模式来实现中介者模式中角色之间的通信；


责任链模式
定义：为请求创建一个接收此次请求对象的链
适用场景：一个请求的处理需要多个对象当中的一个或几个协作处理
优点：请求的发送者和请求的接收者(请求的处理)解耦；责任链可以动态组合；
缺点：责任链太长或者处理时间过长，影响性能；责任链有可能过多；

相关设计模式：
责任链模式和状态模式：在责任链模式中，各个对象并不指定下一个处理的对象者是谁，只有在客户端在设定链条中的顺序以及元素直到被某个责任链元素处理或者整个链条结束；状态模式让每个状态知道自己下一个处理的对象是谁，在编译时就设定好了


访问者模式
定义：封装作用于某数据结构(如List/Set/Map等)中的各元素的操作；可以在不改变各元素的类的前提下，定义作用于这些元素的操作
适用场景：一个数据结构(如List/Set/Map等)包含很多类型对象；数据结构与数据操作分离；
优点：增加新的操作很容易，即增加一个新的访问者(将对数据结构中的元素的操作集中到一个访问者对象中)；根据不同的访问者对相同的数据产生不同的操作行为(核心)；
缺点：增加新的数据结构困难；具体元素变更比较麻烦

相关设计模式：
访问者模式和迭代器模式：都是在某种数据结构上进行处理；访问者模式主要是用于对保存在数据结构中的元素进行某种特定的处理(重点是某种特定的处理)；迭代器模式主要是用于逐个遍历保存在数据结构中的元素(重点是遍历)


状态模式
定义：允许一个对象在其内部状态改变时，改变它的行为；
适用场景：一个对象存在多个状态(不同状态下行为不同)，且状态可相互转换；
优点：将不同的状态隔离；把各种状态的转换逻辑，分布到状态的子类中，减少相相互间的依赖；增加新的状态非常简单；
缺点：装太多的业务场景导致类数目增加，系统变复杂；

相关设计模式：
状态模式和享元模式：两者可配合使用，在状态没有对应的属性时，这种情况下可以使用享元模式在多个上下文之间共享这些状态实例