深入浅出话窗体（一）——窗体事件模型（上）

 转自：51cto 作者：刘铁猛

小序：

   

        工作中最大的挑战并不是那些Mission Impossible，而是你需要一边保持安静、平衡的心态以专注于工作，一边对抗公司体制、社会经济和人际环境对这种心态的破坏——这是对儿永远也解不开的矛盾。

     

   

正文：

   

        记得我在前面一篇文章里提到过：垒砖头垒多少年也成不了建筑师——仍然只会砌墙。同样，堆控件堆多少年也成不了程序员——仍然只会拼凑窗体。成为建筑师的关键在于学习建筑的结构，成为程序员的关键则在于了解程序的结构。今天，就让我们告别在窗体上堆控件，剖析一下窗体与窗体上控件关系——特别是事件的由来以及事件激发（Event Fire）与事件响应（Event Handling）之间的联系。

    

      

事件的由来

   

        传统的面向对象概念中是没有事件（Event）这个东西的，有的只是值域（Field）和方法（Method）。那么事件又是怎么来的呢？在传统的面向对象编程中，如果一个类想调用另一个类的方法，程序员有两种方法：
   

1.        在一个类的方法里通过另一个类的方法名进行直接调用，看上去会是这样：

    

#include  < iostream >

class  A
{
public :
          void  Method()
         {
                   std::cout << " This is A. " << std::endl;
         }
};

class  B
{
public  :
          void  Method(A arg)
         {
                   arg.Method();            //  B与A紧密耦合在一起
         }
};

int  main( int  argc,  char   * argv[])
{
         A a;
         B b;
         b.Method(a);
          return   0 ;
}

   

这样做的好处在于程序结构相当简单，但为这种“简单”所付出的代价就是——类与类之间耦合过于紧密，而使程序几乎不具有弹性和可伸缩性——于是有了另一种方法。

   

2.        在主调类里保有一个函数指针，并将这个指针指向一个函数，在这个函数里再调用其它类的方法。喔~~~你可能会问：“干吗不让这个指针直接指向其它类的方法，还要再借助一个中间函数做跳板呢？”呵呵，答案是：函数指针是不能指向类的成员函数的——《C++必知必会》里有详细解释，如果想再深挖一些，还可以看《深入探索C++对象模型》。这也就是我们常说的“间接引用”或者闻名遐迩的“回调函数”啦:D 大概的样子如下：

    

#include  < iostream >

class  A
{
public :
          void  Method()
         {
                   std::cout << " This is A. " << std::endl;
         }
};

typedef  void  ( * FunctionPointer)();           //  把函数指针定义成一种“类型”

class  B
{
public  :
         FunctionPointer funPointer;              //  声明一个函数指针成员，必需与将被调用的方法类型保持一致
          void  Method()
         {
                   funPointer();                               //  通过函数指针来调用目标方法，B类不与任何类明确耦合
         }
};

void  Function()                                             //  将被间接调用的函数
{
         A a;
         a.Method();
}

int  main( int  argc,  char   * argv[])
{
         B b;
         b.funPointer  =  Function;                   //  成员指针与函数绑定，不存在类与类耦合的问题
         b.Method();                                         //  主调函数-->跳板函数-->被调函数
          return   0 ;
}

   

        这个模型真的非常不错！而且在C/C++世界广为流传。然而，时过境迁，随着.NET时代的来临和指针的不安全性（程序crash和内存泄漏之母:p）日益为人诟病，C#最终放弃了指针——确切地讲是“囚禁”了指针。虽然放弃了指针，但C#并没有放弃这种通过间接调用而降低类间耦合度的模型。微软是怎样做到的呢？原来，微软为.NET Framework添加了一种新的数据类型——委托（Delegate）。

   

        作为一种新的引用型数据类型，委托是一种类。既然是类，就没办法直接当作类的成员来使咯，所以能当作类成员来使用的只能是委托的实例（听起来真的是废话~~但很多初学的朋友就是在这里卡壳）。作为类的成员，委托的实例用起来的确很像函数指针，所以，我不得不再纠正一个流传甚广的谬误——有人说委托是函数指针的升级或委托是“超级函数指针”——实际上应该说委托的实例是函数指针的升级、委托的实例是“超级函数指针”。

    

        对于“超级函数指针”这个title，委托的实例是当之无愧的。它除了可以像函数指针那样“挂接”一个方法（函数被封装在类里之后就称之为“方法”了）外，功能大大超越了函数指针，这体现在：

• 每个函数指针只能挂接一个目标函数，而委托的实例可以使用重载了的+=操作符肆意挂接N多方法，并美其名曰“多播委托”。
• 函数指针具有指针的多种“通病”，而委托作为一种.NET托管类变得非常安全而驯服。
• 函数指针不能指向类的成员函数，委托却可以指向类的成员函数——这倒不是委托的功劳，根本原因在于C#是完全面向对象的语言，所有函数都必须封装在类里变成成员函数（不再有散落在类之外的全局函数），如果委托不能指向成员函数，那委托还有什么用呢:p

        如果阁下想对委托探个究竟，我推荐你去阅读在下的掘文《深入浅出话委托》。

   

        OK，被C#粉饰一新的间接调用模型看上去会是这样：

    

// =<水之真谛>=出品， [url]http://blog.csdn.net/FantasiaX[/url]
using  System;

delegate   void  MyDelegate();            //  声明委托这种类的方法与声明常规类不太一样
                                                              //  它看上去更像是在声明“一个函数指针”，这也正是我上面说的混淆之源。
                                                              //  从语义上讲，这句与上面C++代码中使用typedef把函数指针定义为一种类型是一致的

class  A
{
          public   void  Method( string  name)
         {
                   Console.WriteLine( " Hello, {0}! " , name);
         }
}

class  B
{
          public  MyDelegate deleInstance;                   //  声明一个MyDelegate作为成员
          public   void  Method()
         {
                    if  ( this .deleInstance  !=   null )                   //  安全检验，这是函数指针做不到的
                   {
                             this .deleInstance();
                   }
         }
}

class  Program
{
          static   void  Function()                                        //  作为跳板的函数，将被挂接在委托的实例上
         {
                   A a  =   new  A();
                   a.Method( " Tim " );
         }

          static   void  Main( string [] args)
         {
                   B b  =   new  B();
                   b.deleInstance  +=   new  MyDelegate(Function);              //  创建实例，同时绑定。被绑定的函数返回值和参数类型必须与委托完全一致
                   b.Method();
         }
}

   

        你可能会问：干吗不把委托设计成与A的Method方法类型一致、再到B类中声明一个实例呢？这样不就可以抛开那个什么“当作跳板的函数”、直接调用A类实例的Method方法了吗？

   

        主意不错！但请你考虑这样一个问题：根据客户需求和业务逻辑的需要，A类可能具有几百个参数和返回值类型千奇百怪的方法，那么，你打算专门针对A类开发出几百种委托类型吗？就算你开发出来了，B类的设计人员就乐意为B类声明上如此一大摞专门针对A类的委托实例吗？如果创建B类的程序员接纳了针对A类的几百个委托，那么从针对C到Z这些类的委托呢——要不要也接纳进来？不接纳——除非A和B是两口子；接纳——那B类的代码长度估计不会低于央视大楼！况且，A类、B类以及其它类的设计人员可能根本就不在一个公司、不在一起工作，怎么可能“串通”起来做这种把类耦合在一起的浩大工程呢:p

    

        说了半天光说委托了，事件呢？其实，事件是微软对委托这个概念的进一步升级。就代码而言，事件仅仅是在委托的基础上向前迈进了一小步，但是从程序逻辑的角度上观察，事件却是在思想上向前迈进了一大步！为什么这样讲呢？且听下回分解。

    

TO BE CONTINUE

   

敬请关注：深入浅出话窗体（二）——窗体事件模型（下）