共计 774 个字符，预计需要花费 2 分钟才能阅读完成。
状态模式
无限状态机
1: 状态转换较多，但每个状态的转换业务不简单的，举荐应用查表法。
通过二维数组等形式确定下一个转换的状态，并解决对应业务
2: 状态转换业务较简单的，举荐应用状态模式，应用独自的类来定义状态和状态业务
3: 业务非常简单，状态也很少，间接应用 if else 就能够实现，不须要适度设计
迭代器模式
通过模仿游标的滑动来遍历汇合中的数据
迭代器须要实现 hasNext，currentItem，next 三个办法，用于滑动游标和判断是否迭代完结
遍历过程中不反对元素的增加和删除操作，因为会引起未决后果
访问者模式
一个或多个操作利用到一组对象上，设计的用意是解耦操作和对象自身，放弃类的职责繁多、满足开闭准则已应答代码的复杂性。
举荐应用策略模式代替访问者模式。1: 访问者模式应用重载实现，容易让访问者代码爆炸。2: 不奇妙，不灵便，将一组操作封装在一起，减少性能时须要批改的代码太多。
反对 Double Dispatch 的语言不须要访问者模式，间接动静执行就能够了
备忘录模式
1: 备份以便于复原数据
2: 不能毁坏封装准则
3: 低频率全量备份联合高频率增量备份（redis RDF 和 AOF）
命令模式
1: 将行为封装成对象进行传递
2: 和策略模式的区别在于，每个命令执行的是不同的业务；策略模式指同一个业务的不同实现。
例如：管制电灯的开，关属于命令；是交流电还是直流电给电灯供电属于策略。
解释器模式
典型的场景是编译器的语法解释。
解释器是针对特定的语句进行解释，调用特定的业务代码进行执行的过程。
中介模式
1: 接口对象之间的交互关系，将多对多关系通过中介类转换为一对多。
2: 中介模式和观察者模式的区别在于，观察者关系是单向固定的，中介则能够是双向的。
3: 中介模式接管音讯后进行业务编排调度。
4: 副作用：可能会产生一个大而全的上帝类，蕴含类所有的业务代码。（是否能够用命令模式进行拆分？）
