更新方法模式涉及到我们平日设计模式时用的最多的一种东西,类似unity3d里面的update函数,在超级玛丽里,它可以模拟小乌龟小蘑菇在出现后的行为。哪怕是像象棋一样的游戏,我们不用随时更新它的行为(因为是由玩家触发的),但我们也需要更新它的动画。所以非常常见。
这里的默认设定是由一个数组储存着这些需要update的对象。
问题在于:
- 为了让多个对象同时独立的运转,我们也许也要使用多线程。(需要参考11章 字节码模式)
- 独立过程中的顺序问题,一个已经在A更新中死去的动物,不应该去读它的更新。这怎么办?标记为死亡。更新之后再删除;从底边遍历;如果由一个数组维护这这些对象,那么在更新前储存当前对象列表的长度,只更新之前的对象。
字节码模式看了,发现类似解释器模式?回到最开始的框架挑战里,需求是希望玩家在构建它的方法时,是一种非常自由的状态。这似乎和解释器模式相当?
对。可以挑战一下这样去设计。
我们把操作行为定义为某一种操作,而把对象作为一种实体(当然,它们仍然是可以互相交换的。)
解释器模式中提到文法。每一个文法是一个类。
莫非,真的可以通过使用文法,处理我的框架挑战?
这又和haskell这种解释器有什么关联呢?感觉会非常有趣