Iterator抽取迭代基类/Memento抽取备忘管理类/Interpreter终结非终结解释

Iterator模式-双向关联/聚合，Aggregate类是容器类需要将特定的迭代器创建出来返回Iterator基类指针，Iterator基类接口定义了访问容器的方法，Iterator特定子类定义了针对不同的聚合容器的实现遍历操作返回容器元素，这样容器返回的Iterator就可以遍历自己元素。也就是遍历操作从容器分离出来了，因为每一种类型的容器需要提供不同的Iterator子类，所以这种方式也会大量增加类的数量，当有稳定数量的容器（或者数据主体）时候才采用这样的分离方法，当然不仅仅是遍历其它类型的操作分离也是 可以的。

Iterator UML：

与其它模式关系：

Composite ：迭代器常被应用到象复合这样的递归结构上。

Factory Method：多态迭代器靠Factory Method来例化适当的迭代器子类。

Memento：常与迭代器模式一起使用。迭代器可使用一个 Memento来捕获一个迭代的状态。迭代器在其内部存储Memento。

现在编程语言都有统一的迭代器，很少需要自己编写，除非自己定义了一些容器，或者用这种迭代的思想不一定用于遍历中，将其它类型的操作分离独立出来解耦。

Memento模式-单向关联，不仅仅是数据主体创建一个备忘录类，需要保存的时候保存到备忘录中，需要恢复数据状态的时候从备忘录中得到(可以按条件查询获得不同的状态）；而且更好的方式是要一个备忘录的管理者类，通过备忘录的管理者得到不同的备忘录类，更好的将备忘录类接口抽象，提供多个备忘录类时候易于拓展。

Memento UML：

很多涉及到历史记录的都需要使用该模式分离主体和保留的数据状态。

Interpreter模式-单向关联，对频繁出现需要处理的事情抽象为一个迷你语言-脚本，然后针对每个语句含义写一个解释器类，解释器关联语句内容基类，解释器有终结解释器不关联解释器基类解释结束，非终结解释器需要关联解释器基类（其实是其它子解释器）解释不了的传递下去解释。每个不同的语句内容需要编写一个对应的解释器。

Interpreter UML:

自己编写脚本解释器（材质脚本翻译器）时候，可以使用，或者重复的命令也可以抽取成命令进行解释执行。

interpreter和Command模式区别: Command模式是在命令发出者和接受者之间插入了一个命令，命令需要接受者初始化，命令类注册给命令发出者，命令发出者直接执行命令就可以了，所以命令模式只是命令的转发解耦作用；而解释器模式是将一种动作声明为命令，然后解释命令的含义，尤其是可以多个动作可以一起发出的时候。

     当设计一个游戏主角状态时候如果内部状态间切换比较多且限制较多那么用状态模式，如果需要执行一个命令或多个连续命令分别解释那么可以用解释器模式，如果都是单一的命令有一个或多个命令接受者时候需要用命令模式。因为一个命令只能对一个主角且主角状态限制比较多，且不需要多个命令一起解释，所以对主角执行一个命令，那么用状态模式比较好，状态管理器有各个状态的实例，状态管理器设置一个状态执行动作，然后管理器再执行需要的动作，也就是在当前状态下执行需要的动作，状态子类会在执行动作时候会调用状态管理类设置下一个状态子类，且调用状态管理类来执行。如果状态之间的关系因为引入一个新的状态而变更太大，那么还是需要C风格的枚举常量较好，没有引入复杂的模式，大家也看得明白透彻，改动也是差不多量的。

Interpreter和Chain of Resposibility模式区别：Chain of Resposibility是抽象出Handle基类，拥有设置下一个处理者函数（但子类不设置），有当前的处理函数，处理不了就交给下一任，也可以有默认处理函数全部处理不了就交给它，Chain of Resposibility和状态模式的区别是状态子类之间是知道对方的且有状态管理类，但是Chain of Resposibility子类之间不知道对方且没有管理类(也可以抽取出来），只有客户端知道下一任处理者是谁(客户端需要处理调整责任链顺序）。Interpreter是区分叶子节点和枝节点，且都是可以解释文本内容的（Interpreter是一个内容多个解释器，Chain of Resposibility是一个内容一个处理类），Interpreter不拥有默认解释者。