delegate-interface

//转自 sysword

delegate是c++函数指针的.net版,在delegate的使用上sun和m$之间有很大的争议，由于java不支持delegate，在.net平台下除非十分必要，一般我在设计时不考虑使用delegate.

根据m$的文档，delegate是在内部使用了一个类似包装器的东东，可以在一个delegate里调用一系列的函数，所以效率比较直接接口调用要低2-3倍，所以除非十分必要，一般不要使用delegate.
单纯比较delegate和interface，可以把delegate理解成只有接口函数的接口，但二者侧重点不同，interface的语义性更强， 而delegate只是表明函数签名，语义性不强。在.net类库里也常看到一些只有一个函数的接口，而不用delegate来表示。
在某些情况下使用delegate是必须的。这就是有嵌套类(inner class)或使用了第三方类或已既成代码的情况。如果要通过接口去访问一个类的功能的话，这个类必须把相应功能通过接口暴露出来，但有时候既有代码没有 实现这样的接口，这种情况下使用delegate是二者的一个折衷。
一般说来，如果从头进行设计编码，使用delegate的地方都可以通过暴露一个类似接口的途径实现。

虽然delegate是.net的特性，有某些方面很多超出interface的方便之处，虽然m$在拼命反驳sun的观点，在基于种种理由，但在设计中慎用delegate是必要的

 //转自晴月浩雪

什么时候适合用接口？

接口通常用于一组事件回调函数的定义。在这个时候，你通常不可能只绑定其中的一个事件函数，而需要connect他们的全部。

这种情况下，如果我们不用接口定义，而采用delegate容易让回调函数的书写者因delegate的语法灵活性而犯一些明显的错误或造成程序结构的不合理。

用inteface实现事件机制的最佳的例子之一就是通讯程序的接口。几乎所有的通讯程序，都有connect、disconcect和recievedate的事件要处理，而且几乎每个程序（足够安全、可信赖并且节约资源的程序）都要同时响应这三个事件。

什么时候适合用委托？

接口的特点就是即便只回调接口内的一个事件，也要实现和定义几乎全部的事件。这样子编程，对于程序员来说充斥着空函数的实现显然不方便维护， 同时也浪费了大家的时间。而如果把每个事件函数封装为独立的interface，又很明显会造成过度设计（及其数量巨大的单函数接口掩盖了程序主体结构， 不利于维护和理解）。所以，并不是所有人都满意用interface。

所以，有了signal/slot、bind和delegate（其实就本质目的来说都是一回事）。但他们的设计目的明显是为了弥补那些使用interface会造成不便的场合。

其中一个这样的场合就是界面中的各种事件处理。举例说，响应鼠标左键按下消息，不意味着其它任何别的消息将有必要被同时响应


===============其它====================

观点：
我只是一个C++程序员，偶然造访这里，对.NET和Java的理解还很粗浅。实际上，delegate/bind和interface /connect这两种机制都是需要的，它们是对事件进行不同程度的抽象中所使用的不同技术。也许没有了其中任何一个，我们都可以完成设计任务，但一定会 带来这样或那样的麻烦。

性能：
从我个人的角度讲，delegate是非常有机会将其性能提高到很快的（依赖于C++标准委员会或.NET的标准化改善进程），但 interface则很难。interface的机制是虚函数及纯虚类，其自身存在着相当程度的消耗。delegate本质上是对特定功能函数指针，函数 指针自身性能可以作到几乎没有任何损失。

总结：
1.该用interface用interface（实际上非常适合的地方不算很多）。该用delegate的地方用delegate。
2.既然delegate有可能被滥用，那么最好的方法就是通过影响标准委员会、或者一些人为的规定及改造使其更安全，而非摒弃它。否则，等于因为原子能可以用于战争，所以不发展核电科技一样荒谬。