我眼中委托的真正面貌(一)
2009-05-07 08:26:53 来源:WEB开发网核心提示: 看到区别了吗?呵呵…… 此时InitializeComponent()关于事件挂接的那句话已经不见了,因为这次的MyEvent并不是一个事件专用的委托对象,我眼中委托的真正面貌(一)(7),而是一个普通的委托实例对象,不会自动被C#的编辑器识别,委托最大的优势所
看到区别了吗?呵呵…… 此时InitializeComponent()关于事件挂接的那句话已经不见了,因为这次的MyEvent并不是一个事件专用的委托对象,而是一个普通的委托实例对象,不会自动被C#的编辑器识别。所以,我在主窗口类的构造方法中人为添加了一句代码:
this.userControl11.MyEvent += new Ctrleven.UserControl1.MyEventHander(this.VirtualEvent);
它的作用其实和上一段代码中那句是相同的,就本质而言都是在一个类中操控另一个类的委托对象而已,只不过因为我们没有严格按照C#中的事件声明方式来实现事件机制,因此,这句代码C#的编辑器不会很友好的替你生成,而是要靠你自己来写。呵呵……
可见,程序运行的效果和上一段代码大致相同。
在这里,我想纠正大家的几个误区。平时,我经常听到人们谈论,说所谓委托就是将自己写好的一段代码作为参数传入另一个方法中。没错,用委托的确可以实现类似的说法,比方说某一个方法的参数表中的一个参数是委托类型,这样子的确是可以的。但是,可以实现这种效果的先决要素首先是我们可以利用委托来传递一段代码(也就是一个方法)。所以说真正起到传递方法效果的不是方法中的参数,而是委托对象本身。使用委托对象本身来实现跨类、跨线程甚至跨空间传递方法,这种实现形式的使用频率要比仅仅将委托作为参数,以实现将代码传入另一个方法这样的实现形式来的高得多得多。
好,写到这里,我想应该可以稍微阐述一下我自己的观点了。呵呵……
个人认为,委托最大的优势所在就是——其兼有对象和方法二者的性质。我们既可以将一个委托实例对象作为对象来看待甚至操控,亦可以将其作为一个现成的方法来调用。(未完待续)
更多精彩
赞助商链接