《游戏编程模式》阅读笔记 02 更新方法模式和子类沙盒模式

更新方法模式涉及到我们平日设计模式时用的最多的一种东西，类似unity3d里面的update函数，在超级玛丽里，它可以模拟小乌龟小蘑菇在出现后的行为。哪怕是像象棋一样的游戏，我们不用随时更新它的行为（因为是由玩家触发的），但我们也需要更新它的动画。所以非常常见。

这里的默认设定是由一个数组储存着这些需要update的对象。

问题在于：

1. 为了让多个对象同时独立的运转，我们也许也要使用多线程。（需要参考11章 字节码模式）
2. 独立过程中的顺序问题，一个已经在A更新中死去的动物，不应该去读它的更新。这怎么办？标记为死亡。更新之后再删除；从底边遍历；如果由一个数组维护这这些对象，那么在更新前储存当前对象列表的长度，只更新之前的对象。

字节码模式看了，发现类似解释器模式？回到最开始的框架挑战里，需求是希望玩家在构建它的方法时，是一种非常自由的状态。这似乎和解释器模式相当？
对。可以挑战一下这样去设计。
我们把操作行为定义为某一种操作，而把对象作为一种实体（当然，它们仍然是可以互相交换的。）

解释器模式中提到文法。每一个文法是一个类。
莫非，真的可以通过使用文法，处理我的框架挑战？
这又和haskell这种解释器有什么关联呢？感觉会非常有趣