行为型设计模式
策略模式
定义
定义了算法家族，分别封装起来，让他们可以互相替换，让算法的变化不会影响到使用算法的用户
UML类图
适用场景
- 系统有很多类，而他们的区别仅仅在于他们的行为不同，希望能动态的选择一种行为
- 系统需要动态的在集中算法中选择一种
优缺点
优点：避免使用多重条件转移语句，也提高了算法的保密性和安全性
缺点：客户端必须要知道所有的策略类，并自行决定使用哪一个策略类，会产生很多策略类
模板方法模式
定义
定义一个算法骨架，允许子类为一个或多个步骤提供实现，可以使子类在不改变算法骨架的情况下重新定义算法的某些步骤
UML类图
适用场景
- 一次性实现一个算法的不变部分，并将可变行为留给子类实现
- 子类中公共行为被提取出来并集中到一个公共父类中，以避免代码重复
优缺点
优点：提高复用性、扩展性
缺点：使用的是继承关系，类数目的增加，也就增加了系统实现的复杂度
观察者模式
定义
定义对象之间的一对多依赖，让多个观察者对象同时监听某一个主题对象（被观察者），当主题对象发生变化时，他的所有依赖者（观察者）都会收到通知并更新
UML类图
适用场景
- 关联行为场景，建立一套触发事件的机制
优缺点
优点：观察者和被观察者之间建立一个抽象的耦合，所以增加观察者或被观察者会很容易扩展，并且观察者模式支持广播通信
缺点：观察者之间有过多细节依赖，提高时间消耗以及程序复杂度，要尽量避免循环调用
迭代器模式
定义
提供一种方法，顺序访问一个集合对象中的各种元素，而又不暴露该对象的内部结构表示（内部结构表示就是不同容器，比如有些对象存储在集合中，有些对象存储在数组中）
UML类图
适用场景
- 访问一个集合对象的内容而无需暴露他的内部结构表示
- 为遍历不同的集合结构提供一个统一接口
优缺点
优点：分离了集合对象的遍历行为
缺点：类的个数会成对增加
责任链模式
定义
为请求创建一个接收此次请求对象的链
UML类图
适用场景
- 一个请求的处理需要一个或多个对象协作处理
优缺点
优点：请求的发送者和接收者解耦，并且责任链可以动态的组合
缺点：责任链太长、过多或处理时间过长会影响性能
命令模式
定义
将请求（命令）封装成对象，以便使用不同的请求，确定了应用程序中对象的职责以及他们之间的通信方式
UML类图
适用场景
- 请求调用者和请求接收者需要解耦，使得调用者和接收者不直接交互
- 需要抽象出等待执行的行为
优缺点
优点：降低请求者和接收者之间的耦合，容易扩展新请求或一组请求
缺点：命令的无限扩展会增加类的数量，提高了系统实现复杂度
备忘录模式
定义
保存一个对象的某种状态，以便在适当时机恢对象
UML类图
适用场景
- 保存及恢复数据相关业务场景
优缺点
优点：将存档信息的封装，为用户提供一种可恢复机制
缺点：资源占用多
状态模式
定义
允许一个对象在其内部状态改变时，改变他的行为
UML类图
适用场景
- 一个对象存在多个状态，不同状态下的行为不同，这些状态可以互相转换
优缺点
优点：将不同状态隔离，把各种状态的转换逻辑分布到状态的子类中，减少相互之间的依赖，增加新状态也很简单
缺点：状态多的业务场景会导致类数目增加，使得系统复杂
访问者模式
定义
封装作用于某种数据结构中的各种操作，也就是说在不改变各元素的类的前提下，定义作用于这些元素的操作，被访问者需要对外提供一个接待访问者的接口
UML类图
适用场景
- 当一个数据结构包含很多类型对象
- 数据结构和数据操作分离
优缺点
优点：增加新的操作很容易，增加一个新的访问者即可
缺点：增加新的数据结构困难，具体元素变更比较麻烦
中介者模式
定义
定义一个封装一组对象，如何交互的对象，通过使用对象明确的相互引用来促进松散耦合，并允许独立的改变他们的交互
UML类图
适用场景
- 系统中对象之间的存在复杂的引用关系，产生相互依赖关系结构混乱，并且难以理解
- 对于交互的公共行为，若需改变行为则可增加新的中介者类
优缺点
优点：将一对多转化成了一对一，减少了类之间的耦合，降低了程序的复杂度
缺点：中介者过多，导致系统复杂
解释器模式
定义
给定一个语言，定义他的文法的一种表示，并定义一个解释器，这个解释器使用该文法来解释语言中的句子，即为了解释一种文法而创建的解释器
UML类图
适用场景
- 某个特定类型问题发生频率足够高
优缺点
优点：语法由很多类表示，容易扩展语言
缺点：当语法规则数目太多时增加了系统复杂度
Comments NOTHING