简述：
本节主要是针对行为型模式，下面为大家一一道来。
行为型设计模式：
13. Interpreter（解释器）
给定一个语言，定义它的文法的一种表示，并定义一个解释器，这个解释器使用该表示来解释语言中的句子。
适用性：
-
当有一个语言需要解释执行, 并且你可将该语言中的句子表示为一个抽象语法树时，可使用解释器模式。而当存在以下情况时该模式效果最好：
1.该文法简单,对于复杂的文法, 文法的类层次变得庞大而无法管理。此时语法分析程序生成器这样的工具是更好的选择。它们无需构建抽象语法树即可解释表达式, 这样可以节省空间而且还可能节省时间。
2。效率不是一个关键问题,最高效的解释器通常不是通过直接解释语法分析树实现的, 而是首先将它们转换成另一种形式。例如，正则表达式通常被转换成状态机。但即使在这种情况下, 转换器仍可用解释器模式实现, 该模式仍是有用的。
image
个人理解
该设计模式相对而言比较少用，在它的类图当中，我们可以看到解析表达式的类结构有组合模式的影子，也就是一棵树。通过这颗树，我们可以生成有层次结构的复杂的解析规则。
14. Template Method（模板方法）
定义一个操作中的算法的骨架，而将一些步骤延迟到子类中。TemplateMethod 使得子类可以不改变一个算法的结构即可重定义该算法的某些特定步骤。
适用性：
- 一次性实现一个算法的不变的部分，并将可变的行为留给子类来实现。
- 各子类中公共的行为应被提取出来并集中到一个公共父类中以避免代码重复。这是Opdyke 和Johnson 所描述过的“重分解以一般化”的一个很好的例子[ OJ93 ]。首先识别现有代码中的不同之处，并且将不同之处分离为新的操作。最后，用一个调用这些新的操作的模板方法来替换这些不同的代码。
-
控制子类扩展。
image
个人理解
如果模板方法大家感觉不好理解，可以想想面向对象三大特性之一继承。在属性和行为上提取共性的地方，将差异的地方放在子类中去实现。
15. Chain of Responsibility（责任链）
使多个对象都有机会处理请求，从而避免请求的发送者和接收者之间的耦合关系。将这些对象连成一条链，并沿着这条链传递该请求，直到有一个对象处理它为止。
适用性：
- 有多个的对象可以处理一个请求，哪个对象处理该请求运行时刻自动确定。
- 你想在不明确指定接收者的情况下，向多个对象中的一个提交一个请求。
-
可处理一个请求的对象集合应被动态指定
image
个人理解
责任链模式和Android开发中View的点击事件分发有有些类似，对于处理请求的接受者而言，有几点需要确定，一是形成链式结构。二是针对请求有统一的处理接口。
16. Command（命令）
将一个请求封装为一个对象，从而使你可用不同的请求对客户进行参数化；对请求排队或记录请求日志，以及支持可撤消的操作。
适用性：
- 在不同的时刻指定、排列和执行请求。一个Command对象可以有一个与初始请求无关的生存期。如果一个请求的接收者可用一种与地址空间无关的方式表达，那么就可将负责该请求的命令对象传送给另一个不同的进程并在那儿实现该请求。
- 支持取消操作。Command的Excute 操作可在实施操作前将状态存储起来，在取消操作时这个状态用来消除该操作的影响。Command 接口必须添加一个Unexecute操作，该操作取消上一次Execute调用的效果。执行的命令被存储在一个历史列表中。可通过向后和向前遍历这一列表并分别调用Unexecute和Execute来实现重数不限的“取消”和“重做”。
- 支持修改日志，这样当系统崩溃时，这些修改可以被重做一遍。在Command接口中添加装载操作和存储操作，可以用来保持变动的一个一致的修改日志。从崩溃中恢复的过程包括从磁盘中重新读入记录下来的命令并用Execute操作重新执行它们。
[图片上传失败...(image-4a2abc-1524224340417)]
个人理解
坦白而言，命令模式并不太好理解，主要是参与者众多：命令的发送者，命令本身，命令的接受者和执行者。我们根据实际业务，捋清几者的关系及接口的调用逻辑，命令模式就容易理解了。可以参看OKHttp请求发送过程。
17. Iterator（迭代器）
提供一种方法顺序访问一个聚合对象中各个元素, 而又不需暴露该对象的内部表示。
适用性：
- 访问一个聚合对象的内容而无需暴露它的内部表示。
- 支持对聚合对象的多种遍历。
-
为遍历不同的聚合结构提供一个统一的接口
image
个人理解
这个没什么好说的，看看Java集合里面的迭代器怎么实现的就能理解了，不常用。
18. Mediator（中介者）
用一个中介者对象封装一系列的对象交互，中介者使各对象不需要显示地相互作用，从而使耦合松散，而且可以独立地改变它们之间的交互。
适用性
- 在面向对象编程中，一个类必然会与其他的类发生依赖关系，完全独立的类是没有意义的。一个类同时依赖多个类的情况也相当普遍，既然存在这样的情况，说明，一对多的依赖关系有它的合理性，适当的使用中介者模式可以使原本凌乱的对象关系清晰，但是如果滥用，则可能会带来反的效果。一般来说，只有对于那种同事类之间是网状结构的关系，才会考虑使用中介者模式。可以将网状结构变为星状结构，使同事类之间的关系变的清晰一些。
-
中介者模式是一种比较常用的模式，也是一种比较容易被滥用的模式。对于大多数的情况，同事类之间的关系不会复杂到混乱不堪的网状结构，因此，大多数情况下，将对象间的依赖关系封装的同事类内部就可以的，没有必要非引入中介者模式。滥用中介者模式，只会让事情变的更复杂。
image
个人理解
上面适用性讲的挺好的。这个类图结构和Actvitiy及View设计结构很相似。实在理解不了这个参看Android Activity和View之间的关系。
19. Memento（备忘录）
在不破坏封装性的前提下，捕获一个对象的内部状态，并在该对象之外保存这个状态。这样以后就可将该对象恢复到原先保存的状态。
适用性：
- 必须保存一个对象在某一个时刻的(部分)状态, 这样以后需要时它才能恢复到先前的状态。
-
如果一个用接口来让其它对象直接得到这些状态，将会暴露对象的实现细节并破坏对象的封装性。
image
个人理解
备忘录模式能够让我们在不了解对象内部状态的情况下保存和恢复现场。
20. Observer（观察者）
定义对象间的一种一对多的依赖关系,当一个对象的状态发生改变时, 所有依赖于它的对象都得到通知并被自动更新。
适用性：
- 当一个抽象模型有两个方面, 其中一个方面依赖于另一方面。将这二者封装在独立的对象中以使它们可以各自独立地改变和复用。
- 当对一个对象的改变需要同时改变其它对象, 而不知道具体有多少对象有待改变。
- 当一个对象必须通知其它对象，而它又不能假定其它对象是谁。换言之, 你不希望这些对象是紧密耦合的。
个人理解
观察者模式在开发中使用频率还是蛮高的，尤其是那种需要异步处理，并且被观察的对象和观察者处于1对多的情况下。
21. State（状态）
允许一个对象在其内部状态改变时改变它的行为。对象看起来似乎修改了它的类。
适用性：
- 一个对象的行为取决于它的状态, 并且它必须在运行时刻根据状态改变它的行为。
-
一个操作中含有庞大的多分支的条件语句，且这些分支依赖于该对象的状态。这个状态通常用一个或多个枚举常量表示。通常,有多个操作包含这一相同的条件结构。State模式将每一个条件分支放入一个独立的类中。这使得你可以根据对象自身的情况将对象的状态作为一个对象，这一对象可以不依赖于其他对象而独立变化。
image
个人理解
下面和策略模式一块讨论
22. Strategy（策略）
定义一系列的算法,把它们一个个封装起来, 并且使它们可相互替换。本模式使得算法可独立于使用它的客户而变化。
适用性：
- 许多相关的类仅仅是行为有异。“策略”提供了一种用多个行为中的一个行为来配置一个类的方法。
- 需要使用一个算法的不同变体。例如，你可能会定义一些反映不同的空间/时间权衡的算法。当这些变体实现为一个算法的类层次时,可以使用策略模式。
- 算法使用客户不应该知道的数据。可使用策略模式以避免暴露复杂的、与算法相关的数据结构。
-
一个类定义了多种行为, 并且这些行为在这个类的操作中以多个条件语句的形式出现。将相关的条件分支移入它们各自的Strategy类中以代替这些条件语句。
image
个人理解
策略模式和状态模式比较像，之前看程序员装逼指南中有一条写到，在遇到if-else或者switch-case语句时，记得要把不同分支的行为抽象成接口，然后把每个分支分别创建一个子类并实现其分支的行为。其实这也体现了状态模式和策略模式的使用条件，就是在不同条件下或者不同的状态下我们有不同的行为方式。
23. Visitor（访问者）
让代码用户在不修改现有类层次结构的前提下，定义该类层次结构的操作。
适用性：
- 一个对象结构包含很多类对象，他们有不同的接口，而你想对这些对象实施一些依赖于其具体类的操作
- 需要对一个对象结构中的对象进行很多不同的而且不相关的操作，而你想避免让这些操作污染这些对象的类
-
定义对象结构的类很少改变，但经常需要在此结构上定义新的操作。
image
个人理解
访问者模式这类图看了确实容易懵逼，我们取几个关键点记住就行了:
- 一个对象结构包含很多类对象
- 定义对象的结构的类很少改变
- 你想对这些对象实施一些具体的操作
如类图所示，我们可以看到，在对象类结构（增加ConcereateElementC）发生改变的时候，对于每个具体的访问者而言就比较麻烦，需要对每个对象定义新的访问操作。如果是仅仅再添加一个访问者就简单许多了。
总结
23种设计模式到这里就简单的捋了一遍。设计模式本身比较难理解，需要扎实的知识基础和丰富的项目经验。学习设计模式是一个循序渐进的过程，大家可以先背下来有哪些设计模式及作用，然后记住大概的适用性和类图。这样在我们阅读源码和进行架构设计的时候，可以一边学习一边思考。来强化我们的学习过程。