设计模式总结—行为型模式

行为型模式

行为型模式涉及到算法和对象间职责的分配。行为模式不仅描述对象和类的模式，还描述了它们之间的通信模式。这些模式刻画了在运行时难以跟踪的复杂的控制流。它们将你的注意力从控制流转移到对象间的联系方式上来。与前面两篇文章里说的创建型模式和结构型模式相比，它们强调的都是静态的类实体之间的关系，而行为型模式着力解决的是类实体之间的通讯关系。

 

常见行为型模式有一下几种，它们分别是观察者模式、模板方法模式、命令模式、状态模式、职责链模式、解释器模式、中介者模式、访问者模式、策略模式、备忘录模式和迭代器模式。

 

 

观察者模式

观察者模式定义了一种一对多的依赖关系，让多个观察者对象同时监听某一个主题对象。这个主题对象发生变化时，会通知所有的观察者对象，使它们能够自动更新自己。

 

使用条件：

当一个对象的改变需要同时改变其它对象，而且不知道具体有多少对象有待改变；一个抽象模式有两个方面，其中一方面依赖于另一方面，将这两者封装在独立的对象中使它们各自独立的改变和复用；当一个对象必须通知其它对象，而它又不能假定其它对象是谁，换句话说，不希望这些对象是紧密耦合的。

 

总的来说观察者模式所作的工作其实就是解除耦合。让耦合的双方都依赖于抽象，而不是依赖于具体。从而使得各自的变化都不会影响另一边的变化。

 

类图如下：

 

 

 

 

模板方法模式

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

 

使用条件：

一些列步骤构成的过程需要执行，这个过程从高层次上看是相同的，但有些步骤的实现可能不同。

 

模板方法模式是通过把不变行为搬移到超类，去除子类中的重复代码来体现它的优势，它是提供了一个很好的代码复用平台。

 

类图如下：

 

 

 

命令模式

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

 

使用条件：

只有在真正需要如撤销/恢复操作等功能时，把原来的代码才可以重构为命令模式。

 

类图如下：

 

 

状态模式

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

 

使用条件：

当一个对象的行为取决于它的状态，并且它必须在运行时刻根据状态改变其它的行为时；当控制一个对象状态转换的条件表达式过于复杂时的情况，把状态的判断逻辑转移到表示不同状态的一系列类当中，可以把复杂的判断逻辑简化。

 

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

 

类图如下：

 

 

职责链模式

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

 

使用条件：

有多个的对象可以处理一个请求，哪个对象处理该请求运行时刻自动确定；想在不明确指定接收者的情况下，向多个对象中的一个提交一个请求。

 

接收者和发送者都没有对象明确信息，链对象自己并不知道链的结构，链之间仅需要保持一个指向其后继者的引用，而不需要它所有的候选接收者的引用。

 

类图如下：

 

 

解释器模式

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

 

使用条件：

当有一个语言需要解释执行，并且你可将该语言中的句子表示为一个抽象语法树时；如果一种特点类型的问题发生的频率足够高，那么可能就值得将该问题的各个实例表述为一个简单语言中的句子。这样就可以构建一个解释器，该解释器通过解释这些句子来解决该问题。

 

解释器模式就是用“迷你语言”来表现程序要解决的问题，已迷你语言写成“迷你程序”来表现具体的问题。

 

类图如下：

 

 

 

中介者模式

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

 

使用条件：

应用于一组对象以定义良好但是复杂的方式进行通信的场合；以及想定制一个分布在多个类中的行为，而又不想生成太多的子类的场合。

 

中介者模式将集体行为封装一个单独的中介者对象来避免这个问题，中介者负责控制和协调一组对象间的交互，中介者充当一个中介以使组中的对象不再相互显示引用，这些对象仅知道中介者，从而减少了相互连接的数目。

 

类图如下：

 

 

访问者模式

访问者模式表示一个作用于某对象结构中的各元素的操作。它使你可以在不改变各元素的类的前提下定义作用于这些元素的新操作。

 

使用条件：

有比较稳定的数据结构或者说数据结构相对稳定的系统，又有易于变化的算法即经常需要在数据结构上定义新的操作。

 

访问者模式增加具体的数据结构是困难的，但增加依赖于复杂对象结构的构建的操作就变得容易，仅需增加一个新的访问者即可在一个对象结构上定义一个新的操作。

 

类图如下：

 

 

策略模式

策略模式定义了一些的算法，把它们一个个封装起来，并且使它们可以相互替换，同时使得算法可独立于使用它的客户而变化。

 

使用条件：

需要在不同时间应用不同的业务规则时可以用策略模式处理这种变化的可能性。

 

策略模式定义了一系列算法的方法，从概念上来看，所有的这些算法完成的都是相同的工作，只是实现不同，它可以以相同的方式调用所有的算法，减少了各种算法类与使用算法类之间的耦合。进一步说的话，策略模式就是用来封装算法的，但在实践中，我们发现可以用它来封装几乎任何类型的规则。

 

类图如下：

 

 

备忘录模式

备忘录模式是在不破坏封装性的前提下，捕获一个对象的内部状态，并在该对象之外保存这个状态。这样以后就可将该对象恢复到原先保存的状态。

 

使用条件：

适用于功能比较复杂的，但需要维护或记录属性历史的类，或者需要保存的属性只是众多属性中的一部分时，这样可以根据保存的信息还原到前一状态；如果在某个系统中使用命令模式，需要实现命令的撤销功能，那么命令模式可以使用备忘录模式来存储可撤销操作的状态；使用备忘录可以把复杂的对象内部信息对其它的对象屏蔽起来；角色状态改变的时候，有可能这个状态无效，这时候就可以使用暂时存储起来的备忘录将状态复原

 

类图如下：

 

 

迭代器模式

迭代器模式提供一种方法顺序访问一个聚合对象中的各个元素，而又不暴露该对象的内部表示。

 

使用条件：

需要访问一个聚集对象，不管这些对象是什么都需要遍历时；需要对聚集有多种方式遍历时；为遍历不同的聚合结构提供一个统一的接口。

 

迭代器模式就是分离了集合对象的遍历行为，抽象出一个迭代器类来负责，这样既可以做到不暴露集合内部结构，又可让外部代码透明的访问集合内部的数据。

 

类图如下：