游戏开发中，回调机制和事件机制的灵活运用

在游戏开发中，回调机制和事件机制是我们解耦比较常用的设计。但各有各的优点，下面我就说一下我个人的一些见解吧。

回调机制的简单的理解：

⑴定义一个回调函数；

⑵在初始化的时候，将回调函数注册给调用者；

⑶当特定的事件或条件发生的时候，调用者调用该回调函数进行处理。

事件机制的简单的理解：

⑴使用者绑定对应事件；

⑵当特定的事件或条件发生的时候，触发者派发事件给管理者；

⑶管理者通过捕获事件，然后冒泡，最终调用使用者绑定的处理方法；

两者其实原理差不多，都是把调用者与被调用者分开，调用者不必关心被调用者的操作。但不同的地方在于，前者是一个直接关系，而后者是通过一个中间者来完成的。

对于回调机制，运用比较多的地方

⑴调用者中持有被调用者的实例；

例如在mvc框架中，controller层往往都会持有view层的实例，可以适当使用回调机制，但在view存在多层嵌套subView时不建议使用，需要多次传入回调，易读性也较差。如图一结构：

图一

⑵被调用者有且仅有多个中的一个；

游戏中的物品tips就是一个很好的例子。tips一般不会小于两个按钮，而且不用地方调用可能需要不同的回调，这时只要在调用时传入回调函数，tips就无需知道点击时的操作，只要调用回调函数就搞定，耦合性也会大大降低。

对于事件机制，运用比较多的地方

⑴在非持有被调用者实例的情况下使用较多；

如图一结果，对于subView来说，如果想调用controller或者其他模块中的任何一个处理方法，就是通过事件来调用，不但可以提高代码的易读性，减少冗余，同时也让各模块之间耦合性非常低。

⑵一次捕获，多个冒泡；

在游戏中，往往一个主角的数据变动或者常用的数据变动都会引起很多界面的刷新，这种情况下用事件机制也是最合适的了。事件管理者只需捕获一次，就可以分发多个绑定者。

类似上述tips的例子，如果用事件处理起来就相对麻烦，同时有很多不必要的开销。