[b]为什么要有委托？[/b]
先看例子，我设计了个MAC水晶按钮，我希望Windows用户都能使用这个漂亮的水晶按钮。不过难题是，我无法设想当用户按下按钮之后会执行什么动作？是弹出对话框，还是执行某个程序？ 这些似乎不是按钮设计者能预测到的，但是又必须加以考虑的。一个解决方法是，设计者除了关注处理按钮自身的效果外，还可能需要留个“后门”给其他用户，而其他用户无需触及这个类的内部实现，就可以改变某些方法的处理规则。比如双击按钮会如何，单击按钮会如何....等等。
从类的提供者的角度来看：我们在设计某个类的时候，可能需要在方法A中执行一些额外的处理，但因为变化太多，或无法预先得知其处理规则，设计者没办法将这部分处理写死在类中，这时候我们就会将这部分交给用户自行处理。换句话说，用户必须注册一个处理函数，当方法A执行的过程中，它会去呼叫（callback)这个被注册的函数。这个函数的正式名称就是“委托方法”。对于类的设计者来说，这种设计方式可以将那些变化不定的细节从类中移除出去，使得类别保持干净稳定。
从类的消费者的角度来看: 我们在使用这个类别的时候，它提供了一种机制，即你在调用某个方法的之前，需要提供一个符合特定签名（signature;即参数与回传值）的方法，才能达到你想要执行的工作。
[b]传统的委托写法[/b]
完成一个委托，需要类的提供者和消费者双方一起努力。类的提供者需要完成以下两件事：
1.声明委托类别。你需要使用关键字 delegate 來定义委托类别的名称，以及传入参数和回传值。
注意这里声明的是一个类（Class)，而不是一个方法(Method)或者变量。编译器在遇到delegate关键字的时候，会将其转译成一个继承System.MulticastDelegate的类。
2. 声明该委托类别的实例。
3. 通过该实例执行委托方法。
举个为某种商品打价格标签例子，商品重量通过传感器被送入一个数据集,而市场部每天会决定该商品的价格，以及是否促销等等策略。因为定价的方法十分多变，如果写在这个数据集里，势必得不断的修改。所以这里我们用委托来解决这个问题。
先看例子，我设计了个MAC水晶按钮，我希望Windows用户都能使用这个漂亮的水晶按钮。不过难题是，我无法设想当用户按下按钮之后会执行什么动作？是弹出对话框，还是执行某个程序？ 这些似乎不是按钮设计者能预测到的，但是又必须加以考虑的。一个解决方法是，设计者除了关注处理按钮自身的效果外，还可能需要留个“后门”给其他用户，而其他用户无需触及这个类的内部实现，就可以改变某些方法的处理规则。比如双击按钮会如何，单击按钮会如何....等等。
从类的提供者的角度来看：我们在设计某个类的时候，可能需要在方法A中执行一些额外的处理，但因为变化太多，或无法预先得知其处理规则，设计者没办法将这部分处理写死在类中，这时候我们就会将这部分交给用户自行处理。换句话说，用户必须注册一个处理函数，当方法A执行的过程中，它会去呼叫（callback)这个被注册的函数。这个函数的正式名称就是“委托方法”。对于类的设计者来说，这种设计方式可以将那些变化不定的细节从类中移除出去，使得类别保持干净稳定。
从类的消费者的角度来看: 我们在使用这个类别的时候，它提供了一种机制，即你在调用某个方法的之前，需要提供一个符合特定签名（signature;即参数与回传值）的方法，才能达到你想要执行的工作。
[b]传统的委托写法[/b]
完成一个委托，需要类的提供者和消费者双方一起努力。类的提供者需要完成以下两件事：
1.声明委托类别。你需要使用关键字 delegate 來定义委托类别的名称，以及传入参数和回传值。
注意这里声明的是一个类（Class)，而不是一个方法(Method)或者变量。编译器在遇到delegate关键字的时候，会将其转译成一个继承System.MulticastDelegate的类。
2. 声明该委托类别的实例。
3. 通过该实例执行委托方法。
举个为某种商品打价格标签例子，商品重量通过传感器被送入一个数据集,而市场部每天会决定该商品的价格，以及是否促销等等策略。因为定价的方法十分多变，如果写在这个数据集里，势必得不断的修改。所以这里我们用委托来解决这个问题。