行为型设计模式

一、 行为型设计模式

行为型设计模式介绍

行为型设计模式关注对象之间的通信，为对象之间的通信提供了最佳实践的模板。行为型设计模式主要包括以下的几种设计模式：

1. 责任链模式
2. 命令模式
3. 解释器模式
4. 迭代器模式
5. 中介者模式
6. 备忘录模式
7. 观察者模式
8. 状态模式
9. 策略模式
10. 访问者模式

以下将分别介绍每种设计模式的定义、应用场景、实现，实例，以及分析每种设计模式的优缺点。

具体设计模式介绍

2.1 责任链模式

1．定义：责任链模式为请求创建了一个接收者对象的链，这种模式给予请求的类型，对请求的发送者和接受者进行解耦。本模式通常每个接收者都包含对另一个接收者的引用，如果一个对象不能处理该请求，那么他会把相同的请求传给下一个接收者，以此类推，接收者就连成了一条链，即责任链。
2．应用场景：想要让一个以上的对象邮寄会处理某个请求的时候，为了避免请求的发送者和接收耦合，让多个对象都有可能接受请求，将这些对象连成一条链，并且沿着这条链传递请求，直到由对象处理它为止。
3. 实现：(1) 拦截的类都实现统一的接口。(2) handler里面聚合自己，在handlerRequest里面判断是否何是，如果没有达到条件向下传递，即递归调用自己。具体实现如图2-1所示：

					  图2-1 责任链模式类图

4. 优点 ：(1) 可以将请求的发送者和接收者解耦。(2) 可以简化对象，因为它不需要知道责任链的结构。(3) 通过改变链内成员或者调用它们的次序，允许动态的新增或者删除责任。
5. 缺点：(1) 不容易观察运行时的特征，有碍于除错。(2) 不能保证请求一定被接收。(3) 可能会造成循环调用。
6. 具体实例：web中的处理request和response的过滤器，使用了过滤器+递归的方式进行实现。

2.2 命令模式

1. 定义：将请求封装成对象，以便使用不同的请求，队列或者日志来参数化其他对象，命令模式也支持可撤销的操作。
2. 应用场景：将一个请求封装成一个对象，从而使您可以用不同的请求对客户进行参数化。在软件系统中，行为请求者与行为实现者通常是一种紧耦合的关系，但是某些场合，比如需要对行为进行记录，撤销或者重做、事务等处理时，这种无法抵御变化的紧耦合的设计就不太合适。
3. 实现：定义三个角色：(1) received真正命令的执行对象。 (2) commad (3) invoker使用命令对象的入口。具体类图如2-2:

                        图2-2命令模式类图															  	     		    

4. 优点：(1) 降低了系统耦合度。 (2) 新的命令可以很容易添加到系统中去。
5. 缺点：使用命令模式可能会导致某些系统有过多的具体命令类。
6. 具体实例：(1) struts 1 中的 action 核心控制器 ActionServlet 只有一个，相当于 Invoker，而模型层的类会随着不同的应用有不同的模型类，相当于具体的 Command。(2) 现实生活中，服务员和厨房的师傅对应着类图中的Invoker和receiver,命令就是点餐的订单。用户可以直接和服务员提交订单即可。不需要和烤串师傅进行交流。可以动态的撤销、增加一些命令。

2.3 解释器模式

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

2. 应用场景：如果一种特定类型的问题发生的频率足够高，那么肯能就值得将该问题的各个实例表述为一个简单语言中的句子。这样就可以构建一个解释器，该解释器通过解释这些句子来解决该问题。

3. 实现：
   

    					图2-3 解释器模式的类图
   

4. 优点： (1) 可扩展性比较好，灵活。 (2) 增加了新的解释表达式的方式。 (3) 易于实现简单文法。

5. 缺点：(1)可利用场景比较少。 (2) 对于复杂的文法比较难维护。 (3) 解释器模式会引起类膨胀。 (4) 解释器模式采用递归调用方法。

6. 具体实例：： (1) 可以将一个需要解释执行的语言中的句子表示为一个抽象语法树。 (2) 一些重复出现的问题可以用一种简单的语言来进行表达。 (3) 一个简单语法需要解释的场景。

2.4 迭代模式

1. 定义： 迭代器模式用于顺序访问集合对象的元素，可以在不需要知道集合对象的底层表示的情况下遍历集合中的内容。C++中的iterator的设计就是使用了这种模式。

2. 应用场景：如果想要使用多种遍历集合的方式，可以使用这种设计模式。如果仅仅只有一种遍历方式，可以直接写一个遍历的具体类即可。因为可以结合配置文件实现多态。

3. 实现：将遍历功能抽象成一个新的iterator类。具体的实现如图2-4
   

    					图2-4 迭代器模式类图
   

4. 优点：(1) 支持以不同的方式遍历一个聚合对象。(2) 迭代器简化了聚合类。(3) 方便扩展不同的遍历方式。(4) 综合来说就是符合了开闭原则。

5. 缺点：会导致类增多，从而增加了系统的复杂性。

6. 具体实例：c++中的迭代器，可以由向前迭代器，向后迭代器等。

2.5 中介者模式

1. 定义：中介者模式又叫调停者模式，提供了一个中介类，用来处理不同类之间的通信。使用中介者模式可以降低多个对象之间通信的复杂性，使得代码易于维护。

2. 应用场景：多个类之间互相耦合，形成了网状结构。

3. 实现：中介者模式使用如左图，右图为使用中介者之前的类图。可以看到，使用中介之后，各类之间的耦合从一对多，变成了一对以，大大降低了类之间的耦合程度。
   
   

    				图2-5 中介者模式的的示意图
   

4. 优点：(1) 是迪米特法则(不和陌生人说话)的的典型。(2) 降低了类的复杂性，将一对多，转化成了一对一，各个通信类之间实现了解耦。

5. 缺点：如果设计的不恰当，中介者对象本身会变得过于复杂。

6. 具体实例：数据库的DataX相当于一个中介，从数据源读取数据，写入到目标段，数据源不需要在维护到不同目标端的同步作业，只需要与DataX通信即可。实现如图2-6:
   

    					图2-6 DataX实现示意图
   

2.6 备忘录模式

1. 定义：保存对象的某个状态，以便在适当的时候恢复对象。备忘录模式可以存储系统关键推向的重要状态，并维护关键对象的封装。

2. 应用场景：再不破坏封装性的前提下，捕获一个对象的内部状态，并在该对象之外保存这个状态。比如用户在请求“撤销”的时候使用的就是备忘录模式。

3. 实现：客户不与备忘录类耦合，与备忘录管理类耦合。具体实现如图2-7所示：
   

    				图2-7 备忘录模式类图
   

4. 优点： (1) 给用户提供了一种可以恢复状态的机制，可以使用户能够比较方便地回到某个历史的状态。 (2) 实现了信息的封装，使得用户不需要关心状态的保存细节。

5. 缺点：消耗资源。如果类的成员变量过多，势必会占用比较大的资源，而且每一次保存都会消耗一定的内存。

6. 具体实例： (1) 后悔药。 (2) 打游戏时的存档。 (3) Windows 里的 ctrl + z。 (4) IE 中的后退。 (5) 数据库的事务管理。

2.7 观察者模式

1. 定义：当对象间存在一对多的关系时，则使用管擦或者模式。比如当一个对象被修改时，会自动通知它依赖的对象。

2. 应用场景：(1) 一个抽象模型有两个方面，其中一个方面依赖于另一个方面。将这些方面封装在独立的对象中使它们可以各自独立地改变和复用。一个对象的改变将导致其他一个或多个对象也发生改变，而不知道具体有多少对象将发生改变，可以降低对象之间的耦合度。(2) 一个对象必须通知其他对象，而并不知道这些对象是谁。(3)需要在系统中创建一个触发链，A对象的行为将影响B对象，B对象的行为将影响C对象……，可以使用观察者模式创建一种链式触发机制。

3. 实现：观察者模式使用三个类 Subject、Observer 和 Client。Subject 对象带有绑定观察者到 Client 对象和从 Client 对象解绑观察者的方法。我们创建 Subject 类、Observer 抽象类和扩展了抽象类 Observer 的实体类。ObserverPatternDemo，我们的演示类使用 Subject 和实体类对象来演示观察者模式。具体类图如2-8所示:

					图2-8 观察者模式类图

4. 优点：(1) 符合开闭原则，找到程序的变化方方面，然后将器和固定不变的方面像分离。(2) 针对接口变成，不针对实现变成。主题使用接口通知观察者。观察者利用接口注册。(3) 多用组合，少用继承。观察者利用组合将许多观察者组合进主题之中。
5. 缺点：(1) 会出现循环调用。(2) 降低被观察者的效率。
6. 具体实例：拍卖的时候，拍卖师观察最高价，然后通知其他竞拍者竞价。

2.8 策略模式

1. 定义：策略模式允许一个类的行为或其算法可以在运行时修改。策略模式创建便是各种策略的对象和一个行为随着策略对象的改变而改变context对象。
2. 应用场景：一个系统由很多类，区分他们的知识他们的直接的行为。
3. 实现：策略模式将这些类封装成一个类。策略模式的类图如图2-9：

					图2-9 策略模式的类图

4. 优点：(1) 算法可以自由切换。(2) 避免使用多重条件判断。(3)扩展性好
5. 缺点：(1) 所有策略类都需要对外暴露。
6. 具体实例：快速排序中自定义的排序器。

2.9 状态模式

1. 定义：在状态模式中，类的行为是基于它的状态改变的，我们创建表示各种状态的对象和一个行为随着状态对象的改变而改变的context对象。
2. 应用场景：(1) 行为随着状态改变而改变的场景。(2) 条件、分支语句的替代。(3) 代码中包含大量与对象状态有关的条件语句。
3. 实现：具体的类图如2-10

					图2-10 状态模式的类图

4. 优点：(1) 允许状态转换逻辑与状态对象合成一体而不是某一个巨大的条件语句块。
5. 缺点：(1) 增加系统类和对象的个数。(2) 状态模式的结构与实现比较复杂，如果使用不当，将导致程序结构和代码的混乱。(3) 状态模式对开闭原则不友好，增加新的状态类需要修改负责状态转换的源码，虽然会小部分修改。
6. 具体实例：根据不同的时间状态，决定不同的计划。

2.10 访问者模式

1. 定义：访问者模式使用一个访问者，改变了元素类的执行算法。通过这种方式，元素的执行算法可以随着访问者的改变而改变。根据此模式，元素对象已接受访问者对象，这样访问者对象就可以处理元素对象上的操作。

2. 应用场景：需要对一个对象结构中的对象进行很多不同的并且不相关的操作，而需要避免让这些操作"污染"这些对象的类，使用访问者模式将这些封装到类中。

3. 实现：在数据基础类里面有一个方法接受访问者，将自身引用传入访问者。具体类图如2-11
   

    				图2-11 访问者模式的类图
   

4. 优点：(1) 符合单一职责原则。(2) 扩展性良好,灵活性好。

5. 缺点：违背了迪米特原则，具体元素对访问者公布细节。

6. 具体实例：设计超市收银系统，碰到了困难，有的按重量计价，有的按物件计价，还有其他计价方式。此时可以使用访问者模式。