深入浅出话窗体(一)——窗体事件模型(上)

 深入浅出话窗体(一)

——窗体事件模型(上)

 作者:CSDN 刘铁猛

   

小序:
   
        工作中最大的挑战并不是那些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#粉饰一新的间接调用模型看上去会是这样:
    
// =<水之真谛>=出品, http://blog.csdn.net/FantasiaX
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

   

敬请关注:深入浅出话窗体(二)——窗体事件模型(下)

   

 

 

 

法律声明: 本文章受到知识产权法保护,任何单位或个人若需要转载此文,必需保证文章的完整性(未经作者许可的任何删节或改动将视为侵权行为)。若您需要转载,请务必注明文章出处为 CSDN 以保障网站的权益;请务必注明文章作者为 刘铁猛 http://blog.csdn.net/FantasiaX ),并向[email protected] 发送邮件,标明文章位置及用途。转载时必须将此法律声明一并转载。保护知识产权,人人有责,谢谢!


Trackback: http://tb.blog.csdn.net/TrackBack.aspx?PostId=1646220


你可能感兴趣的:(事件)