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

我眼中委托的真正面貌（一）2011-06-28 博客园独孤残云首先我们以书中所介绍的委托的由来为起始点展开话题：

在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（"委托挂载的事件调用成功！"）;

        }

    }

}