背景
看了前面的创建模型与结构模型，我们有了类与整体架构如何让他们真正的协调工作这又是一个问题，今天我们进入了有一个复杂的问题——行为模型，他控制类与类之间的通讯与相互控制。解决类之间的复杂的交互项操作，对于解耦有很大的帮助。
模式特点
这里主要介绍五中设计模式的特点与结构，记录下自己的想法。
1. CHAIN OF RESPONSIBILITY(职责链) — 对象行为型模式
1.1 意图
使多个对象都有机会处理请求，从而避免请求的发送者和接收者之间的耦合关系。将这些对象连成一条链，并沿着这条链传递该请求，直到有一个对象处理它为止。
1.2 适用性
在以下条件下使用Responsibility 链：
- 有多个的对象可以处理一个请求，哪个对象处理该请求运行时刻自动确定。
- 你想在不明确指定接收者的情况下，向多个对象中的一个提交一个请求。
- 可处理一个请求的对象集合应被动态指定。
1.3 结构图
1.4 效果
Responsibility 链有下列优点和缺点 :
- 降低耦合度 该模式使得一个对象无需知道是其他哪一个对象处理其请求。对象仅需知道该请求会被“正确”地处理。接收者和发送者都没有对方的明确的信息，且链中的对象不需知道链的结构。结果是，职责链可简化对象的相互连接。它们仅需保持一个指向其后继者的引用，而不需保持它所有的候选接受者的引用。
- 增强了给对象指派职责( Responsibility )的灵活性 当在对象中分派职责时，职责链给你更多的灵活性。你可以通过在运行时刻对该链进行动态的增加或修改来增加或改变处理一个请求的那些职责。你可以将这种机制与静态的特例化处理对象的继承机制结合起来使用。
- 不保证被接受 既然一个请求没有明确的接收者，那么就不能保证它一定会被处理 —该请求可能一直到链的末端都得不到处理。一个请求也可能因该链没有被正确配置而得不到处理。
1.5 注意
感觉这里还是为了大型的项目框架准备的，在android中view类的事件传输貌似就用着这个职责链，感觉应该结合组合模型中的Composite模式，来形成一个链状的结构。
2. COMMAND（命令） — 对象行为型模式
2.1 意图
将一个请求封装为一个对象，从而使你可用不同的请求对客户进行参数化；对请求排队或记录请求日志，以及支持可撤消的操作。
2.2 适用性
当你有如下需求时，可使用Command模式：
- 对于特定操作，可以抽象出待执行的动作以参数化某对象。你可用过程语言中的回调（callback）函数表达这种参数化机制。所谓回调函数是指函数先在某处注册，而它将在稍后某个需要的时候被调用。Command模式是回调机制的一个面向对象的替代品。
- 在不同的时刻指定、排列和执行请求。一个 Command对象可以有一个与初始请求无关的生存期。如果一个请求的接收者可用一种与地址空间无关的方式表达，那么就可将负责该请求的命令对象传送给另一个不同的进程并在那儿实现该请求。
- 支持取消操作。Command的Execute操作可在实施操作前将状态存储起来，在取消操作时这个状态用来消除该操作的影响。 Command接口必须添加一个 Unexecute操作，该操作取消上一次Execute调用的效果。执行的命令被存储在一个历史列表中。可通过向后和向前遍历这一列表并分别调用 UnExecute和Execute来实现重数不限的“取消”和“重做” 。
- 支持修改日志，这样当系统崩溃时，这些修改可以被重做一遍。在Command接口中添加装载操作和存储操作，可以用来保持变动的一个一致的修改日志。从崩溃中恢复的过程包括从磁盘中重新读入记录下来的命令并用Execute操作重新执行它们。
- 用构建在原语操作上的高层操作构造一个系统。这样一种结构在支持事务( transaction)的信息系统中很常见。一个事务封装了对数据的一组变动。Command模式提供了对事务进行建模的方法。Command有一个公共的接口，使得你可以用同一种方式调用所有的事务。同时使用该模式也易于添加新事务以扩展系统。
2.3 结构图
2.4 效果
Command模式有以下效果:
- Command模式将调用操作的对象与知道如何实现该操作的对象解耦。
- Command是头等的对象。它们可像其他的对象一样被操纵和扩展。
- 你可将多个命令装配成一个复合命令。一般说来，复合命令是composite模式的一个实例。
- 增加新的Command很容易，因为这无需改变已有的类。
2.5 注意
这里是吧所有的处理都给放值在一个地方处理。若是复杂可以用composite模式来解决更复杂的问题，这里要慢慢体会他的强大。
3. INTERPRETER(解释器) — 类行为型模式
3.1 意图
给定一个语言，定义它的文法的一种表示，并定义一个解释器，这个解释器使用该表示来解释语言中的句子。
3.2 适用性
当有一个语言需要解释执行 , 并且你可将该语言中的句子表示为一个抽象语法树时，可使用解释器模式。而当存在以下情况时该模式效果最好：
- 该文法简单对于复杂的文法 , 文法的类层次变得庞大而无法管理。此时语法分析程序生成器这样的工具是更好的选择。它们无需构建抽象语法树即可解释表达式 , 这样可以节省空间而且还可能节省时间。
- 效率不是一个关键问题最高效的解释器通常不是通过直接解释语法分析树实现的 , 而是首先将它们转换成另一种形式。例如，正则表达式通常被转换成状态机。但即使在这种情况下, 转换器仍可用解释器模式实现, 该模式仍是有用的。
3.3 结构图
3.4 效果
解释器模式有下列的优点和不足:
- 易于改变和扩展文法 因为该模式使用类来表示文法规则 , 你可使用继承来改变或扩展该文法。已有的表达式可被增量式地改变 ,而新的表达式可定义为旧表达式的变体。
- 也易于实现文法 定义抽象语法树中各个节点的类的实现大体类似。这些类易于直接编写，通常它们也可用一个编译器或语法分析程序生成器自动生成。
- 复杂的文法难以维护 解释器模式为文法中的每一条规则至少定义了一个类(使用BNF定义的文法规则需要更多的类)。因此包含许多规则的文法可能难以管理和维护。可应用其他的设计模式来缓解这一问题。但当文法非常复杂时, 其他的技术如语法分析程序或编译器生成器更为合适。
- 增加了新的解释表达式的方式 解释器模式使得实现新表达式“计算”变得容易。 例如,你可以在表达式类上定义一个新的操作以支持优美打印或表达式的类型检查。如果你经常创建新的解释表达式的方式, 那么可以考虑使用Visiter模式以避免修改这些代表文法的类。
3.5 注意
看了后有点不明觉厉，还要继续研究。
4. ITERATOR(迭代器) — 对象行为型模式
4.1 意图
提供一种方法顺序访问一个聚合对象中各个元素 , 而又不需暴露该对象的内部表示。
4.2 适用性
迭代器模式可用来：
- 访问一个聚合对象的内容而无需暴露它的内部表示。
- 支持对聚合对象的多种遍历。
- 为遍历不同的聚合结构提供一个统一的接口 (即, 支持多态迭代)。
4.3 结构图
4.4 效果
迭代器模式有三个重要的作用：
1. 它支持以不同的方式遍历一个聚合 复杂的聚合可用多种方式进行遍历。例如 , 代码生成和语义检查要遍历语法分析树。代码生成可以按中序或者按前序来遍历语法分析树。迭代器模式使得改变遍历算法变得很容易 ,仅需用一个不同的迭代器的实例代替原先的实例即可。你也可以自己定义迭代器的子类以支持新的遍历。
2. 迭代器简化了聚合的接口 有了迭代器的遍历接口，聚合本身就不再需要类似的遍历接口了。这样就简化了聚合的接口。
3. 在同一个聚合上可以有多个遍历 每个迭代器保持它自己的遍历状态。因此你可以同时进行多个遍历。
4.5 注意
这种结构很奇怪。数据结构类似c语言的结构体，这里主要是为了封装。让我们不知道里面的内容，因为本来list就有循环遍历的功能。
5.1 意图
用一个中介对象来封装一系列的对象交互。中介者使各对象不需要显式地相互引用，从而使其耦合松散，而且可以独立地改变它们之间的交互。
5.2 适用性
在下列情况下使用中介者模式:
- 一组对象以定义良好但是复杂的方式进行通信。产生的相互依赖关系结构混乱且难以理解。
- 一个对象引用其他很多对象并且直接与这些对象通信 ,导致难以复用该对象。
- 想定制一个分布在多个类中的行为，而又不想生成太多的子类。
5.3 结构图
5.4 效果
中介者模式有以下优点和缺点:
- 减少了子类生成 Mediator将原本分布于多个对象间的行为集中在一起。改变这些行为只需生成 Mediator的子类即可。这样各个Colleague类可被重用。
- 它将各Colleague解耦 Mediator有利于各Colleague间的松耦合. 你可以独立的改变和复用各Colleague类和 Mediator类。
- 它简化了对象协议 用 Mediator和各Colleague间的一对多的交互来代替多对多的交互。一对多的关系更易于理解、维护和扩展。
- 它对对象如何协作进行了抽象 将中介作为一个独立的概念并将其封装在一个对象中，使你将注意力从对象各自本身的行为转移到它们之间的交互上来。这有助于弄清楚一个系统中的对象是如何交互的。
- 它使控制集中化 中介者模式将交互的复杂性变为中介者的复杂性。因为中介者封装了协议, 它可能变得比任一个Colleague都复杂。 这可能使得中介者自身成为一个难于维护的庞然大物。
5.5 注意
这个东西其实就是个信息中转站。结构是facade模型的信息交互状态。
分析
以后补充，这个整体的总结太难，暂时水平不够
