Publisher的作用或许要提高一些

[RF-Tar-Railt]

Cesloi 的事件系统是用的”发布--订阅“模型

在C#中，事件在类中声明且生成，且通过使用同一个类或其他类中的委托与事件处理程序关联。包含事件的类用于发布事件。这被称为 发布器（publisher） 类。其他接受该事件的类被称为 订阅器（subscriber） 类。事件使用 发布-订阅（publisher-subscriber） 模型。此处的委托（delegate）相当于一类拥有相同参数类型与返回值类型的方法的统称。

发布器（publisher） 是一个包含事件和委托定义的对象。事件和委托之间的联系也定义在这个对象中。发布器（publisher）类的对象调用这个事件，并通知其他的对象。

订阅器（subscriber） 是一个接受事件并提供事件处理程序的对象。在发布器（publisher）类中的委托调用订阅器（subscriber）类中的方法（事件处理程序）。一个事件可以处理多个经过委托注册的订阅器类中的方法。

对应此处的Cesloi的delegatesystem，Publisher类包含订阅器列表 (Subscriber List) 与绑定事件类型 (Bind Event), 而委托则扩大为EventDelegate，用来处理所有的订阅器类中的事件处理程序（Callable Function）。

如果可行，那么是否可以将委托的概念缩小，塞入发布器类中？
通信模块收到来自api的事件消息，根据类型传递给相应发布器中的委托进行数据分析，再由委托将分析好的参数值传递给订阅器中的处理程序

[RF-Tar-Railt]

目前模型是 事件原始数据（Dict）——委托系统——> 处理好的事件实例（Class）——> 依据事件名选择对应发布器 ——>
该发布器包含的所有订阅器 ——> 事件包含的数据解析为参数列 ——是否通过命令分析器——> 订阅器中的可执行函数

或许可以调整为
事件原始数据（Dict）——依据事件名选择对应发布器 ——> 该发布器中的委托 ——> 处理好的事件实例（Class） ——>
该发布器包含的所有订阅器 ——> 事件包含的数据解析为参数列 ——是否通过命令分析器——> 订阅器中的可执行函数
这时候的委托应该仍与订阅器绑定
甚至来讲，同一类事件也可以有不同的发布者。这可以对应不同外部条件下的发布器

[RF-Tar-Railt]

上游Communicator收到事件后将事件推入事件队列，事件队列处理器按照预先的时间间隔将队头事件推出给相应的发布器。发布器根据事件类型，执行通过由该事件对应的委托注册的订阅器内的回调函数并且将事件数据传递给回调函数，并且已经时间调度器与命令分析器决定是否执行。委托应该绑定一个事件类(Class Type)，当接受发布器的原始数据后传递该事件实例(Object)给订阅器。委托应由发布器决定。

[RF-Tar-Railt]

0.5已实现