读书笔记-设计模式-行为型模式
lazypanda职责链模式
场景
有多个对象可以处理同一个请求，具体是哪个对象由运行时刻自动确定
方案
能够处理请求的对象继承自同一个抽象类，运行时刻组成链状结构。 客户发请求给这条链的第一个对象，如果这个对象能处理则处理，不能处理则交给这条链的下一个对象。
UML表示
命令模式
场景
有时必须向某对象提交请求，但并不知道关于被请求的操作或请求的接受者的任何信息。
方案
将一个请求封装为一个对象，从而使我们可用不同的请求对客户进行参数化；对请求排队或者记录请求日志，以及支持可撤销的操作。 把接受者封装到命令对象里面，然后一起交给invoker，invoker在将来的某一时刻会回调这个命令对象，这时命令对象会给接受者发消息，执行动作。
UML表示
动态活动图
其他
在函数式语言中，由于函数可以很方便的传来传去，就不需要命令模式这么麻烦了。
解释器模式
场景
如果一种特定类型的问题发生的频率足够高，那么可能就值得将该问题的各个实例表述为一个简单语言中的句子。
方案
实现一个DSL的解释器
UML表示
其他
一般情况下不需要这么复杂的方案，所以这里记的很简略。
迭代器模式
场景
聚合对象需要提供一种方法来让别人访问它的元素
方案
C++标准库里对所有容器都提供了迭代器
UML表示
中介者模式
场景
很多对象可能以各种各样的方式连接，每个对象都知道很多其他对象，他们耦合在一起。
方案
用一个中介者对象，专门负责控制和协调一组对象间的交互。
UML表示
备忘录模式
场景
有时需要捕获一个对象的状态，但是暴露其内部状态又违反封装的原则
方案
做一个备忘录对象，可以存储另一个对象（originator）在某个瞬间的内部状态。 只有originator有资格初始化并访问该备忘录。
UML表示
观察者模式
场景
定义对象间的一种一对多的依赖关系，当一个对象的状态发生改变时，要通知所有依赖于它的对象
方案
一个对象Observer可以向对象Subject发出订阅请求，而subject维护了所有订阅者的集合。 当subject状态有更新时，就向所有订阅者发出update消息，而Observer要有能力处理update消息。
UML表示
状态模式
场景
对象需要在其内部状态改变时改变它的行为
方案
建模为有限状态机
UML表示
策略模式
场景
有一系列可相互替换的算法
方案
将算法封装为策略类
UML表示
模板方法模式
场景
一个算法的骨架是确定的，但其中的一些步骤可以有多种实现方法
方案
将算法骨架实现为模板方法，然后有差别的步骤延迟到子类中实现
UML表示
访问者模式
场景
数据是稳定的，但是要经常添加针对这些数据的操作。
方案
- 将操作封装为visitor
- 客户以具体的visitor为参数向数据发送accept消息
- 数据处理accept消息的方法是，反过来给visitor发送visit消息，同时也把自己交给visitor
- 接下来，visitor根据发来的数据的类型，进行具体的处理
UML表示
其他
- 添加新操作只需要增加一个对应的visitor，其中定义对各种数据类型的访问处理。