我眼中委托的真正面貌（一）

核心提示：首先我们以书中所介绍的委托的由来为起始点展开话题：在C或C++中有时为了开启一个子线程，我们会用到如下的方法：HANDLE hThread;DWORD ThreadID;hThread = CreateThread(NULL,0,(LPTHREAD_START_ROUTINE)ThreadFunc,NULL,0,&Th

首先我们以书中所介绍的委托的由来为起始点展开话题：

在C或C++中有时为了开启一个子线程，我们会用到如下的方法：

HANDLE hThread;

DWORD ThreadID;

hThread = CreateThread(NULL,0,(LPTHREAD_START_ROUTINE)ThreadFunc,NULL,0,&ThreadID);

以上语句中的ThreadFunc()为C++中的一个全局方法。因为C++或者C语言都是允许面向过程的，因此全局函数是可以存在的。但大家不妨试想一下，如果是C#或者Java这种纯面向对象的语言，我们要怎么做呢？

思考一下，在C#中你可以用如下的代码来实现相同的效果吗？

Tread subTread = new Tread();

subTread.Start(EntryPoint);

这样做是明显不对的！在C++中函数名EntryPoint实际上就是一个全局函数指针，它表明了子线程的入口地址。然而，在C#中这样的情况是绝对不存在的！原因很简单——作为一门面向对象的语言，C#中很少有方法是独立于对象而存在的。

在C#中调用方法时，这些方法通常都要与一个类的实例相关联。也就是说，如果要传递一个方法，那么就必须把该方法的相关细节包装在一种新型的对象中。于是，伴随着这种需要，委托随之诞生。

以上只是《C#高级编程》一书中所提到的委托的产生过程，在这里我并不想深究其中的机制，而是以此为线索，深层次的挖掘C#中委托的实质用途及其优势所在。

这样一来，首先单纯根据委托的定义可知，委托可以简单的包装方法的细节：

1.简单的包装方法

namespace SimpleDelegate

{

　　　 public partial class Form1 : Form

　　　 {

　　　　　　　 public Form1()

　　　　　　　 {

　　　　　　　　　　　 InitializeComponent();

　　　　　　　 }

　　　　　　

　　　　　　 //定义委托

　　　　　　　 private delegate void MyDelegete();

　

　　　　　　 //声明委托的实例变量，并为其挂载相应的方法

　　　　　　　 private MyDelegete MyObjdelegate = new MyDelegete(MyFun);

　

　　　　　　　 private void button1_Click(object sender, EventArgs e)

　　　　　　　 {

　　　　　　　　　　　 MyObjdelegate();

　　　　　　　 }

　

　　　　　　　 static private void MyFun()

　　　　　　　 {

　　　　　　　　　　　 MessageBox.Show("委托挂载的事件调用成功！");

　　　　　　　 }

　　　 }

}