10.1.2 第二步：定义事件成员

10.1.2  第二步：定义事件成员

事件成员使用C#关键字event定义。每个事件成员都有一个给定的可访问性(通常都为public，以便于其他代码也可以访问这个事件成员)、一个表示即将被调用方法的原型的委托类型以及一个名称(可以是任意有效的标识符)。NewMail类中事件成员的形式如下：

internal class MailManager {

    //第二步：定义事件成员
    public event EventHandler NewMail;
    ...
} 

NewMail是事件的名称。事件成员的类型是EventHandler，其含义为所有事件通知的接收者都必须提供一个原型和EventHandler 委托类型相匹配的回调方法。由于泛型System.EventHandler委托类型的定义如下：

public delegate void EventHandler
    (Object sender, TEventArgs e) where TEventArgs: EventArgs;

因此方法原型必须具有下述形式：

void MethodName(Object sender, NewMailEventArgs e);

注意 许多人可能会觉得奇怪，为什么事件模式要求sender参数的类型始终为Object。毕竟，因为MailManager是惟一一个引发拥有NewMailEventArgs对象的事件类型，所以回调方法的原型如下：

void MethodName(MailManager sender, NewMailEventArgs e);

因为继承的缘故，该模式中要求sender参数的类型为Object。但是如果MailManager用作SmtpMailManager的基类，情况又会怎么样呢？在这种情况下，回调方法应使sender参数的原型为SmtpMailManager，而不是MailManager，但这种情况不会发生，因为SmtpMailManager只继承了NewMail事件。因此，希望使用SmtpMailManager引发事件的代码必须将sender参数的类型强制转换为SmtpMailManager。换句话说，类型间的强制转换仍然需要，因此，sender参数的类型也可能转换为Object。

其次，将sender参数的类型转换为Object仅仅是为了灵活。这样可以允许多个类型使用同一个委托，这个委托提供了一个传递NewMailEventArgs对象的事件。例如，尽管PopMailManager类不是从MailManager类派生的，但是PopMailManager类也可以使用这个委托。

此外，事件模式同样要求委托定义和回调方法将派生自EventArgs的参数命名为e。上述情况的惟一解释就是为了对模式增加一致性，使开发人员可以比较容易地学习和实现模式。生成源代码的工具(例如Microsoft的Visual Studio)同样知道调用参数e。

最后，事件模式要求所有的事件处理程序的返回类型都为void。必须这样做的原因是引发事件后可能要调用几个回调方法，因此不可能使每个回调方法都返回一个值。让返回类型为void就不会允许回调返回值。然而，在Microsoft.NET Framework类库中有一些事件处理程序，例如ResolveEventHandler，就没有遵守Microsoft自己规定的模式，因为ResolveEventHandler事件处理程序返回一个类型为Assembly的对象。