设计模式纵横谈学习笔记(5)

Command命令模式（行为型模式）

一、耦合与变化

耦合是软件不能抵御变化灾难的根本性原因。不仅实体对象与实体对象之间存在耦合关系，实体对象与行为操作之间也存在耦合关系。

创建型设计模式解决的创建者和被创建对象的耦合问题； 结构型设计模式解决的是实体对象和实体对象的耦合问题； 行为型设计模式解决的是实体对象和行为操作之间的耦合问题。 二、动机

在软件构建过程中，“行为请求者”与“行为实现者”通常呈现一种“紧耦合”。但在某些场合——比如需要对行为进行“记录、撤销/重做（undo/redo）、事务”等处理，这种无法抵御变化的紧耦合是不合适的。

在这种情况下，如何将“行为请求者”与“行为实现者”解耦？将一组行为抽象为对象，可以实现二者之间的松耦合。 三、意图

将一个请求封装为一个对象，从而使你可用不同的请求对客户（客户程序，也是行为的请求者）进行参数化；对请求排队或记录请求日志，以及支持可撤销的操作。 四、要点

Command模式的根本目的在于将“行为请求者”与“行为实现者”解耦，在面向对象语言中，常见的实现手段是“将行为抽象为对象”。

实现Command接口的具体命令对象ConcreteCommand有时候根据需要可能会保存一些额外的状态信息。

通过使用Composite模式，可以将多个“命令”封装为一个“复合命令”MacroCommand。

Command模式与C#中的Delegate（Delegate是把函数指针抽象成了为一种可被调用的行为对象）有些类似。但两者定义行为接口的规范有所区别：Command以面向对象中的“接口-实现”来定义行为接口规范，更严格，更符合抽象原则；Delegate以函数签名来定义行为接口规范，更灵活，但抽象能力比较弱。

Interpreter解释器模式（行为型模式）

一、动机（Motivation）

在软件构建过程中，如果某一特定领域的问题比较复杂，类似的模式不断重复出现，如果使用普通的编程方式来实现将面临非常频繁的变化。 在这种情况下，将特定领域的问题表达为某种语法规则下的句子，然后构建一个解释器来解释这样的句子，从而达到解决问题的目的。 二、意图（Intent）

给定一个语言，定义它的文法的一种表示，并定义一种解释器，这个解释器使用该表示来解释语言中的句子。 三、要点

Interpreter模式的应用场合是Interpreter模式应用中的难点，只有满足“业务规则频繁变化，且类似的模式不断重复出现，并且容易抽象为语法规则的问题”才适合使用Interpreter模式。 使用Interpreter模式来表示文法规则，从而可以使用面向对象技巧方便地“扩展”文法。

Interpreter模式比较适合简单的文法表示，对于复杂的文法表示，Interpreter模式会产生比较大的类层次结构，需要求助于语法分析生成器这样的标准工具。

Mediator中介者模式（行为型模式）

一、依赖关系的转化

二、动机（Motivation） 在软件构建过程中，经常会出现多个对象互相关联交互的情况，对象之间常常会维持一种复杂的引用关系，如果遇到一些需求的更改，这种直接的引用关系将面临不断地变化。

在这种情况下，我们可使用一个“中介对象”来管理对象间的关联关系，避免相互交互的对象之间的紧耦合引用关系，从而更好地抵御变化。 三、意图（Intent）

用一个中介对象来封装一系列的对象交互。中介者使各对象不需要显式的相互引用，从而使其耦合松散，而且可以独立地改变它们之间的交互。 四、要点

将多个对象间复杂的关联关系解耦，Mediator模式将多个对象间的控制逻辑进行集中管理，变“多个对象互相关联”为“多个对象和一个中介者关联”，简化了系统的维护，抵御了可能的变化。

随着控制逻辑的复杂化，Mediator具体对象的实现可能相当复杂。这时候可以对Mediator对象进行分解处理。

Facade模式是解耦系统外到系统内（单向）的对相关联关系 Mediator模式是解耦系统内各个对象之间（双向）的关联关系

Iterator迭代器模式（行为型模式）

一、集合内部结构与外部访问

二、动机（Motivation）

在软件构建过程中，集合对象内部结构常常变化各异。但对于这些集合对象，我们希望在不暴露其内部结构的同时，可以让外部客户代码透明地访问其中包含的元素；同时这种“透明遍历”也为“同一种算法在多种集合对象上进行操作”提供了可能。

使用面向对象技术将这种遍历机制抽象为“迭代器对象”为“应对变化中的集合对象”提供了一种优雅的方式。 三、意图（Intent）

提供一种方法顺序访问一个聚合对象中的各个元素，而又不暴露该对象的内部表示。 四、要点

迭代抽象：访问一个聚合对象的内容而无需暴露它的内部表示。 迭代多态：为遍历不同的集合结构提供一个统一的接口，从而支持同样的算法在不同的集合结构上进行操作。

例如假设我们有一个求和算法

它可以操作在多个支持迭代器的集合上，如果把这个算法写成ArrayList的话，就会非常受限制。同时我们更可以用C#的Foreach语句来写。

我们的算法应该是独立的，写的时候应该尽量操作接口，这样我们写好一个算法，就能应对N种集合的变化，使得同样的算法能在不同的集合上操作。

迭代器的健壮性考虑：遍历的同时更改迭代器所在的集合结构，会导致问题。

也就是说，我们在迭代的时候，应该只是读取操作，不能更改容器的接口，例如遍历的时候删除一个元素，这样是不可以的。容器的结构师绝对不能碰的，一旦结构更改，遍历就会出问题。

下面这种情况对i进行更改，是不会影响原来的数组内容的，因为i是int类型，它只是一份拷贝。

我们一定要给用户提供尽量纯只读的迭代。保证每个元素被且只被遍历一次。

百度搜索“77cn”或“免费范文网”即可找到本站免费阅读全部范文。收藏本站方便下次阅读，免费范文网，提供经典小说综合文库设计模式纵横谈学习笔记(5)在线全文阅读。