设想一个情景来理解事件与委托的使用：有一家IT公司，董事长不希望自己的雇员在上班时间玩游戏，但又不可能每时每刻都盯着每个雇员，因此，他希望使用一种新的方式实现监视雇员的效果：如果有雇员违反规定，某个设备或专门的监查人员将自动发出一个消息通知他，董事长只需要在事情发生时进行处理。
因此，这个用例实际上是两种类型——董事长类与雇员类——之间的交互，下面的代码将给读者展示如何使用委托与事件机制实现这种交互：
首先，我们需要在董事长类与雇员类之间定义一个委托类型，用于传递两者之间的事件，这个类型就是一个监视设备或专门负责打小报告的监查人员：
public delegate void DelegateClassHandle();
定义一个委托的过程类似方法的定义，但它没有方法体。定义委托一定要添加关键字delegate。由于定义委托实际上相当一个类，因此可以在定义类的任何地方定义委托。另外，根据委托的可见性，也可以添加一般的访问修饰符，如public、private和protected。
委托的返回值类型为void，这并非表示委托类型本身带有返回值，该返回值类型是指委托的目标函数类型，即它委托的一个事件处理函数返回值是void类型。
新建一个雇员类Employee，其代码如下：
public class Employee
{
public event DelegateClassHandle PlayGame;
public void Games()
{
if (PlayGame != null)
{
PlayGame();
}
}
}
雇员类Employee代码中定义了一个DelegateClassHandle类型的事件PlayGame，它的定义方式也很特殊，首先必须使用关键字event，表示PlayGame是一个事件，同时还必须声明该事件的委托类型为DelegateClassHandle，即将来由该类型的委托对象负责通知事件。
如果有雇员开始玩游戏，它将执行Games方法，而只要该方法一被调用，就会触发一个事件PlayGame，然后董事长就会收到这个事件的消息——有人在玩游戏了。
董事长类代码如下，他有一个方法Notify用于接收消息：
public class Admin
{
public void Notify()
{
System.Console.WriteLine("someone is playing game");
}
}
Employee的PlayGame事件如何与Admin的Notify方法关联起来呢？只需通过事件绑定即可实现，具体过程如下列代码：
Employee employee = new Employee();
Admin admin = new Admin();
employee.PlayGame += new DelegateClassHandle(admin.Notify);
employee.Games();
请大家注意事件绑定的代码：
employee.PlayGame += new DelegateClassHandle(admin.Notify);
通过DelegateClassHandle将两个类的交互进行了绑定，当employee.Games方法调用后，触发PlayGame事件，而该事件将被委托给admin的Notify方法处理，通知董事长有雇员在上班时间玩游戏。
但董事长并不满足这种简单的通知，他还想知道究竟是谁在上班时间违反规定。显然，现在委托对象必须传递必要的参数才行，这个要求也可以很容易地办到。事件的参数可以设置为任何类型的数据，在.NET框架中，还提供了事件参数基类EventArgs专门用于传递事件数据。
从该EventArgs类派生一个自定义的事件参数类CustomeEventArgs，这个类型将携带雇员姓名和年龄信息：
public class CustomeEvetnArgs : EventArgs
{
string name = "";
int age = 0;
public CustomeEvetnArgs()
{ }
public string Name
{
get { return this.name; }
set { this.name = value; }
}
public int Age
{
get { return this.age; }
set { this.age = value; }
}
}
修改委托类型DelegateClassHandle的定义，让其携带必要的参数：
public delegate void DelegateClassHandle(object sender, CustomeEvetnArgs e);
雇员类的代码修改后如下：
public class Employee
{
private string _name;
public string Name
{
get { return _name; }
set { _name = value; }
}
private int _age;
public int Age
{
get { return _age; }
set { _age = value; }
}
public event DelegateClassHandle PlayGame;
public void Games()
{
if (PlayGame != null)
{
CustomeEvetnArgs e = new CustomeEvetnArgs();
e.Name = this._name ;
e.Age = this._age;
PlayGame(this, e);
}
}
}
在Games方法中，首先新建一个CustomeEventArgs对象，然后设置了必要的属性Name和Age。
董事长的通知方法也必须相应地进行修改：
public class Admin
{
public void Notify(object sender, CustomeEvetnArgs e)
{
System.Console.WriteLine(e.Name+" is "+e.Age.ToString());
}
}
将两个类型对象进行关联的代码也需要进行相应的修改：
Employee employee = new Employee();
employee.Name = "Mike";
employee.Age = 25;
Admin admin = new Admin();
employee.PlayGame += new DelegateClassHandle(admin.Notify);
employee.Games();
修改后的代码运行的结果是，当Mike调用Games方法玩游戏时，会自动触发PlayGame事件，而该事件携带相关信息通知admin，后者的Notify方法将接收到数据并输出“Mike is 25”，告诉董事长是Mike，25岁，正在上班时间玩游戏。
委托是可以多路广播（Mulitcast）的，即一个事件可以委托给多个对象接收并处理。在上面的用例中，如果有另一位经理与董事长具有同样的癖好，也可以让委托对象将雇员的PlayGame事件通知他。
首先定义经理类：
public class Manager
{
public void Notify(object sender, CustomeEvetnArgs e)
{
System.Console.WriteLine(sender.ToString() + "-" + e.Name);
}
}
经理Manager类型的Notify方法与Admin一致，他也接受到相应的信息。
委托的多路广播绑定的方法仍然是使用+=运算符，其方法如下面的代码所示：
Employee employee = new Employee();
employee.Name = "Mike";
employee.Age = 25;
Admin admin = new Admin();
Manager manager = new Manager();
employee.PlayGame += new DelegateClassHandle(admin.Notify);
employee.PlayGame += new DelegateClassHandle(manager.Notify);
employee.Games();
执行该方法，读者将看到admin和manager的Notify方法都会被事件通知并调用执行。通过这样的方法，董事长和经理都会知道Mike在玩游戏了。
如果董事长不希望经理也收到这个通知，该如何解除PlayGame对manager的事件绑定呢？同样非常简单，在employee.Games方法被调用前执行下列语句即可：
employee.PlayGame -= new DelegateClassHandle(manager.Notify);
最后需要提醒读者注意的，Employee类中的Games方法在触发事件PlayGame之前需要判断该事件是否为null。当employee对象的Games方法触发事件PlayGame后，必须有一个目标函数来处理这个事件，而该语句正是判断该目标函数是否存在。如果将这个判断去掉，且对事件不进行任何绑定而直接调用Games方法，程序将在事件PlayGame处弹出一个NullReferenceException的异常。
读者能够从委托与事件的代码中得出什么结论吗？两个需要存在调用关系的类型，在各自的实现中却没有编写实际的调用代码，它们只是通过一个事件和一个第三方的委托类型完成了消息的传递过程。两个类型之间不存在任何的紧密耦合，它们看似松散地通过一个委托对象中通信，实现了本书一直宣传的“高聚合”和“低耦合”观点。
本文来自CSDN博客，转载请标明出处：http://blog.csdn.net/chiangbt/archive/2008/01/17/2050174.aspx