|
楼主 |
发表于 2024-4-26 15:39:21
|
显示全部楼层
四。事件机制的缺点
人月神话说过,没有银弹。
说人话就是没有万能的绝招。
按马克思的说法,就是生产关系还要适应具体的生产力呢。
事件机制最大的缺点就是它最大的优点,低耦合,高自由。
太不自由心智负担高,太自由了信之负担也会高。
首先,使用事件机制后,你不能依赖处理代码的顺序。
同一个事件,先进行A处理,再进行B处理,是不应该依赖的,哪怕框架支持,你也无法确保所有的模块都按你的意愿排序,所以无法强调顺序。
这个有个变通的妥协发案,就是个事件加入生命周期。
比如,响应mud的原始行的事件
'core.online'
可以演变为
'core.beforeonline','core.afteronline'。
如果还不够,那就需要'core.beforebeforeonline','core.afterafteronline',然后N个before和N个After,丑的一逼。
那个实际的例子,我的机器的初始化阶段的代码
- App.Raise("BeforeInit")
- App.Raise("Init")
- App.Raise("InitMod")
- App.Raise("Ready")
- App.Raise("AfterReady")
- App.Raise("Intro")
复制代码 你就说丑不丑吧
其次,太过自由。
事件一但抛出,理论上它就是个孤儿,没人知道它从哪里来,没人知道它到哪里去。
说人话就是,一个事件,进入事件系统后,没法确认谁为发起(raise)事件负责,谁为处理(handle)事件处理。
谁都能发,谁都能处理,大家都是平等的,关系和国产狗血剧的感情关系图差不多。
最恐怖的是,你丢一个石头出去,不知道有多少院子里的狗会叫。
这个是事件系统本身最大优点的黑暗面,无法避免。
对这一点,我只能用两个方法来降低副作用。
第一是事件本身命名,都带上合适的作用域。
比如我一直举例都是 'core.'开头的事件。代表事件由core模块发起,非core模块不该发起这个事件。
第二是处理机制。
对于需要直接发出指令(对mud发送内容)的处理函数,
我用了一个伪状态机进行处理,确保对应事件最多只有一个处理函数进行处理
在这个模式下,将事件处理的优势缩小为 只有一个处理函数,或者被忽视不处理。
来降低复杂度。
绝大部分方案,都同时有优点,有缺点。
作为拿主意的人,只能做到,尽量利用足优点,尽量规避掉缺点
不管什么方案,都不是万能的。
|
|