如何打造一个带类型的事件系统

Creator 3.x
#43

ikun 2.5 year :ok_hand: :rofl:

#44

最佩服一个事件系统都可以有自己一套理论的人了 :+1:

#45

两个emitter 更难用

#46

我只能说明你的不好用是针对你自己的，原因如下

  1. 分布式定义事件类型是最差的方案，因为不能一眼看到有什么事件，只有自己知道或者利用编辑器查看引用，这本身就是浪费时间和协作开发的拖累

  2. 事件类型只需要定义一次，和 Enum 方案相比只是多了几个参数但是保证了类型安全

  3. 事件必须关注参数，除非你不用事件参数，或者不在乎事件参数类型和数量是否正确
    你的方案就是直接忽略事件参数校验，我可以随便传递任何类型的事件参数但是不会在编辑器报错，只有运行时报错

1赞
#47

最最佩服的是拿这套理论去成功说服团队使用 :rofl:

#48

给你看个以前开发过的游戏的集中定义的例子。400 多个事件同一个地方定义。就算一眼看（那又能看出什么）：

image
image1098×1818 388 KB

分布式有分布式的好处。第一个就是，分布式方案如果只有一个地方，那就退化成集中式的。它是集中定义方案的超集。

框架层事件和业务事件可以分工。A 模块和 B 模块的人可以协作各自定义各自的事件。你的意思是 2 个要写一起？

image
image2044×1094 412 KB

还是说，你理解的分布式定义是某个文件里只定义一个事件的那种？

#49

你的上面的问题是没有划分事件粒度，比如全局事件，子游戏事件，模块事件。所有事件放在一起就会像你举例那样

我之前的确以为你说的是每个模块把公共事件放在自己模块脚本内。所以这里误解了，一眼看到事件类型的优势是可以方便自己找到其他人已经写好的事件使用，但是事件太多也是一个问题

而我之前举例的 EventTarget 是一个类型，可以根据自己需要实例化 N 个对象，我自己使用也是分全局和单独的模块或者子游戏事件对象，所以是否造成事件堆积看自己怎么使用

#51

我懂了，你还有分模块的多个 EventTarget 对象。那的确是可以用这种方式。

#52

看了这么多事件系统，其实有一点我觉得要重视一下，就是在dispatch过程中，处理函数remove 自己（或其他同事件）的情况，会让外层派发循环index偏移，跳过1-n个事件触发。

解决办法很多也很简单，在事件派发中触发remove的时候，给要移除的handler记一个删除标志，等派发完成后删除，就可以解决。不过我看大家都没做这个处理。

#53

官方的 EventTarget 处理了。可以放心使用官方版本。

#54

哈哈，我是说没用官方的，自己写的那几个嘛。

#55

逆序就行了

#56

逆序也行，但逆序只能处理remove自己的情况，改成删除标志可以处理数组里面任意几个被删除的情况。并且删除标志是一种通用的方式，适用于各种外层迭代器出现失效的情况。