设计模式——行为模式（一）

前面我们讨论了设计模式——创建型模式和设计模式——结构型模式，现在我们来讨论设计模式中的行为模式。

行为模式是用在不同对象直接划分职责和算法的抽象，行为模式不仅涉及到类和对象，还涉及到类与对象之间如何进

行关联。

可分为行为类模式和行为对象模式两种：

1.行为类模式使用继承机制在类间分派行为。

2.行为对象模式使用对象复合而不是继承。一些行为对象模式描述了组对等的对象怎样相互协作以完成其中任何一个i

额对象都无法单独完成的任务。这里一个重要的问题是对等对象如何相互了解对方。对等对象可以保持显式的对对方

的引用，但是那会增加他们的耦合度。在极端情况下，每一个对象都要了解所以其他的对象。

行为型模式包括：

解释器（Interperter）：

提供一个如何把语言元素包括在程序中的定义。

模板（Template）：

提供算法的一个抽象定义。

职责链（Chain of Responsibility）：

把请求从链中的一个对象传到下一个对象，直到请求被响应为止。通过这种方式去除对象之间的耦合。

命令（Command）：

用简单的对象表示软件命令的执行，支持登录和取消操作。

迭代（Iterator）：

提供一种顺序访问一个类中一系列数据的方式。

中介者（Mediator）：

定义了如何用一个对象简化对象之间的通信，使对象之间不必相互了解。

备忘录（Memento）：

定义了如何保存一个类的实例内容，以便以后恢复它。

观察者（Observer）：

定义了一种把改动通知给多个对象的方式。

状态（State）：

允许一个对象在其内部状态改变时修改它的行为。

策略（Strategy）：

将算法封装到类中。

访问者（Visitor）：

在不改变类的前提下，为一个类添加多种操作。

解释器（interpreter）

定义：

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

 

结构图：

 

解释：一般的执行过程是这样的，Client读取Context中的信息，根据某种原则将其划分成多个部分，针对每一部分，

构造相应的解释器，并将Context信息传入解释器中进行处理。这里的问题是Client必须要清楚Context细节和具体解释

器中间的关联。我们可以在Client和Interpreter之间构造一个“解释器工厂”，用来根据Context生成相应的解释器实

例，同样，如果解释器的执行过程和数据无关，我们可以为“解释器工厂”上追加“单例”模式，构造一个解释器

池。这些都是可以根据需求做的进一步的优化。

例子：音乐解释器

 

模板方法（TemplateMethod）

 

定义：

定义一个操作中的算法的骨架,而将一些步骤延迟到子类中。模板方法使得子类可以不改变一个算法的结构即可重定

义该算法的某些特定步骤。

结构图：

 

解释：

可以看出，对于子类来说，它是不需要重写TemplateMethod方法的，而只需要实现父类的抽象方法。对于客户端来说，当它实例化某个子类后，可以直接调用TemplateMethod方法来完成某项业务。

例子：考题抄错

 

职责链模式（Chain of Responsibility）

 

定义：

使多个对象都有机会处理请求，从而避免请求的发送者和接收者之间的耦合关系。将这个对象连成一条链，并沿着这

条链传递该请求，直到有一个对象处理它为止。

结构图:

解释：

我们可以创建很多个Handler的实现类，并通过设置SetSuccessor来将这些Handler“串”在一起。那么如何触发所有

的Handler呢？这里和Decorator有点儿类似，我们可以通过调用SetSuccessor.HandlerRequest来实现。这样用户只

需要关心最开始的Handler，而不必关心后面都还有哪些其他的Handler。

例子：申请加薪

 

命令模式（Command）

 

定义：

将一个请求封装为一个对象，从而使你可用不同的请求对客户进行参数化；对请求排队或记录请求日志，以及支持可

撤销的操作。

结构图：

解释：

从图中，我们可以看到，当Client端需要执行某项业务时，它需要构造一个Invoker对象，它负责发出请求，会生成一个Command对象。同时我们看到有一个Receiver对象，它是用来实现具体业务的，我们在ConcreteCommand中，会引用这个对象，来完成具体业务。

例子：吃烤羊肉串