.net event & delegate 之我见

用了.net的事件之后，一致困惑，觉得event这个东西其实就是delegate，没啥用，结果在某个网站找到一个文章，大致这样说:

----------------------------------------------------------------------------- 

1、委托的局限

如果单纯用委托，对于事件的发布者B来说，假设它发布事件e，对于事件e，它目前已经知道有A和C对象需要订阅这个事件。所以，它就申明两个委托对象引用（本质上类似于函数指针），然后让A和C对象来采用类似回调的机制订阅和响应事件。

如果后来，有个对象D也需要订阅B的事件e，它怎么办呢？一种情况是D修改B的一个委托对象引用，把自己的处理方法包装成一个委托对象付给它。这样，D就抢夺了A或者C的订阅。否则，就需要修改B的代码，添加一个类似的委托对象引用，以便让D来使用。

这样做的后果是事件发布者B需要申明很多委托对象的引用变量。结果是弄得代码维护比较混乱，并且使用者也很多，依赖关系也不容易搞清楚，容易发生错误。

2、事件的引入

有了委托，就提供了类似回调一样的功能。但是，回调机制需要事件发布者和事件订阅者双方的共同参与和努力。也就是，每增加一个订阅者，那么发布者对象就需要提供一个委托引用，让订阅者挂钩。

如果事件的发布者发布一个事件以后就不在关心谁来订阅它，那么以后的处理就交给了使用者，而发布者不再关心事件处理者的问题。

---------------------------------------------------------------------------

 

对此我非常不认同，看如下代码:

public event EventHandler myevt;

public EventHandler myevt;

其实上述两句话均定义了一个事件或者说是一个代理，而且使用过程中也没有什么区别，至少我觉得。

想来想去觉得唯一可能有区别的地方是，event是一个关键字,那么可能在reflection 或者类似地方，可以通过类型枚举到这些"事件"从而显示在ui编辑器或者什么地方；

而纯粹使用代理则无法区分到底是事件或者一般的回调,当然也可已通过访问属性控制，不过这样一来还不如直接定义一个event关键字。

另外从reflector观察，如果使用了event实际上.net会自动生成一个add/remove方法。