设计模式之行为型模式

开篇，向大家介绍一下行为型模式。

行为型模式涉及算法和对象间职责的分配。

行为型模式同样分为行为型类模式和行为型对象模式

行为型类模式使用继承机制在类间分配行为。

行为型对象模式使用对象复合而不是继承。↓

一些行为对象模式描述了一组对等的对象怎样相互协作以完成其中任一个对象都无法单独完成的任务。

eg：mediator、chain of responsibility，observer

其他行为型对象模式常将行为封装在一个对象中并将请求指派给它。

eg：strategy，state，command，visitor，iterator。

行为型设计模式共包括以下几个模式：

• 观察者模式
• 命令模式
• 职责链模式
• 状态模式
• 解释器模式
• 中介者模式
• 访问者模式
• 策略模式
• 备忘录模式
• 迭代器模式
• 模块方法模式

接下来我们详细的学习一下各个模式：

观察者模式（Observer）

内容：定义对象间的一种一对多的依赖关系，当一个对象的状态发生改变时，所有依赖于它的对象都得到通知并被自动更新。

特点：

1、使用该模式的目的：

将一个系统分割成一系列相互协作的类有个副作用，就是需要维护相关对象的一致性。这就会产生高耦合，故而使用该模式进行解耦合。让耦合双方都依赖于抽象，而不是依赖于具体。从而使各自的变化都不会影响另一边的变化。

2、何时使用该模式：

当一个对象的改变需要同时改变其他对象时；而且它不知道具体有多少对象有待改变。

当一个抽象模式有两个方面，其中一个方面依赖于另一方面，通过观察者，可以将两者封装在独立的对象中使它们各自独立变化

不足：

该模式还是存在抽象通知者依赖抽象观察者的情况，故而如果没有这个接口，就无法实现了。而且调用方法单一，只有一个更新，如果有其他需求是无法实现的。

结构图：

 命令模式（Command）

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

作用：

1、能比较容易的设计一个命令队列。

2、在需要的情况下，可以比较容易地将命令记入日志

3、允许接收请求的一方决定是否要否决请求

4、可以容易地实现对请求的撤销和重做。

5、由于加进新的具体命令类不影响其他的类，因此增加新的具体命令类很容易。

6、命令模式把一个操作的对象与知道怎么执行一个操作的对象分割开。

结构图：

 

职责链模式（Chain of Responsibility）

内容：使多个对象都有机会处理请求，从而避免请求的发送者和接收者之间的耦合关系。将这个对象连成一条链，并沿着这条链传递该请求，直到有一个对象处理它为止。

优点：

接收者与发送者无需明确对方信息，链中的对象自己也不知道链结构，如此可简化对象的相互连接，他们仅需一个指向其后继结点的引用，而不需保持它所有的候选接受者的引用。

可以随时地增加或修改处理一个请求的结构。增强了给对象指派职责的灵活性。

要注意一个请求极有可能到了链的末端都得不到处理，或者因为没有正确的配置而得不到处理。

结构图：

 

状态模式（State）

内容：

当一个对象的内在状态改变时允许改变其行为，这个对象看起来像是改变了其类。

优点：

① 将与特定状态相关的行为局部化，并且将不同状态的行为分割开来。目的：消除庞大的条件分支语句

即：将特定的状态相关的行为都放入一个对象中，由于所有与状态相关的代码都存在与某个ConcreteState中，所以通过定义新的子类可以很容易地增加新的状态和转换。

② 通过把各种状态转移逻辑分布到State的子类中。目的：减少相互间的依赖。

应用：

当一个对象的行为取决于它的状态，并且他必须在运行时刻根据状态改变它的行为时，就可以考虑使用状态模式。

结构图：

策略模式