设计模式之优缺点（二）

前言

上篇博客描述的是创建型模式和结构型模式中的模式的优缺点及适用场景，接下来就再学习一下行为型模式中模式的优缺点和适用场景吧。

正文

1. 观察者模式

优点：松耦合，使各自的变化不会影响另一边的变化
缺点：不能让以封装的观察者实现特定接口
适用场景：一个对象改变需要同时改变其他对象，而且不知道具体有多少对象有待改变

2. 模板方法模式

优点：代码复用，去除子类的重复代码，使子类摆脱重复的不变行为的纠缠
缺点：若可变行为多，会使类的个数增加，使系统更庞大。
适用场景：当要完成在某一细节层次一致的一个过程或一系列步骤，但其个别步骤在更详细的层次上实现可能不同时

3. 命令模式

优点：把请求一个操作的对象与知道怎么执行一个操作的对象分隔开；能较容易地设计一个命令队列；较容易地将命令记入日志；允许接受请求的一方决定是否要否决请求；容易地实现对请求的撤销和重做；由于加进新的具体命令类不影响其他的类，所以增加新的具体命令类很容易。
缺点：会有过多的具体命令类
适用场景：请求一个操作的对象与知道怎么执行一个操作的对象不直接交互

4. 状态模式

优点：将与特定状态相关的行为局部化，并且将不同状态的行为分割开来；消除庞大的条件分支语句；通过把各种状态转移逻辑分布到状态的子类之间，来减少相互间的依赖
缺点：类和对象个数的增加，会导致系统开销变大
适用场景：当一个对象的行为取决于它的状态，并且它必须在运行时刻根据状态改变它的行为时

5. 职责链模式

优点：降低耦合度；增强了给对象指派职责的灵活性
缺点：一个请求极有可能到了链的末端都得不到处理，或者因为没有正确配置而得不到处理
适用场景：多个对象都有机会处理请求，哪一个对象最终处理并不不确定

6. 解释器模式

优点：易于改变、扩展和实现文法
缺点：由于每一条规则至少定义了一个类，因此包含许多规则的文法可能难以管理和维护。
适用场景：如果一个特定类型的问题发生的频率足够高，那么可能就值得将该问题的各个实例表述为一个简单语言的句子。构建解释器，解释器通过解释这些句子解决问题。

7. 中介者模式

优点：降低耦合；站在宏观的角度去看待系统
缺点：由于中介者的控制集中化，是交互复杂性成了中介者的复杂性
适用场景：一组对象以定义良好但是复杂的方式进行通信的场合；想定制一个分布在多个类的行为，而又不想生成太多的子类的场合。

8. 访问者模式

优点：增加新的操作容易
缺点：增加新的数据结构困难
适用场景：数据结构相对稳定的系统

9. 策略模式

优点：减少耦合；简化单元测试，因为每个算法都有自己的类，可以通过自己的接口单独测试；消除条件语句，避免大量判断
缺点：会产生很多具体策略类
适用场景：需要使用多重条件选择语句来实现很多行为

10. 备忘录模式

优点：当角色的状态改变的时候，有可能这个状态无效，这时候就可以使用暂时存储起来的备忘录将状态复原；撤销功能
缺点：资源消耗大，可能占用大量的存储空间
适用场景：功能比较复杂的，但需要维护或记录属性历史的类，或者需要保存的属性只是众多属性中的一小部分，备忘录可以根据保存发状态信息还原到前一状态。

11. 迭代器模式

优点：既不暴露集合的内部结构，又可让外部代码透明地访问集合内部的数据
缺点：增加类时，聚合类和迭代类需要成对增加，所以增加了系统的复杂性
适用场景：当你需要访问一个聚集对象，而且不管对象是什么都需要遍历的时候，也就是当你需要对聚集有多种方式遍历时，可以考虑用迭代器模式

后记

设计模式的优缺点及适用场景就先描述到这里了。在以后的代码中一定要适当使用设计模式，让我们设计的代码更好。