shensr

新手路过。膜拜下装配脑袋。 MS已经在C#中实现Lambda Expression。

国际贸易中我国服装企业面临的绿色壁垒问题的思考de选题的目的和意义?

这工具真不错，太好用了。

我有个软件,叫"图像批处理专家",我用的是1.3版,才五百KB,很小,不用安装直接用.它可以给照片批量全部加上拍照日期\文字图形说明\水印\调整亮度对比度等等,很方便!
下载地址:http://blog.chinaunix.net/upfile/070914084721.rar

谢谢你！

我是用C语言做了一个小游戏的毕业设计什么都可以过了。老师说就是开题报告不行呀，那为大哥大姐帮我想想呀

不错不错!

Very good software.
You could make it keep the aspect beetwen image size and text...
If i add timestamp to a 2mp imagem the text is bigger than in a 7mp image...

我在上一封回信的第一段中应该说得比较清楚，分层计算并不会降低任务分解/结果合并的复杂度（显然容器不可能知道每一种特定计算任务的分解/合并算法，而我也不打算建立一种新的语言去描述这种算法）！

说的更具体点，我们把并行计算简单抽象为如下三个循环的过程：
1. 父任务的分解
2. 子任务的执行
3. 子结果的合并
上述三个过程是并行计算任务必须自己负责的工作，任何一个平台都无法完全替编程者自动完成上述三个过程。换句话说，不可能存在一套平台能将任何串行计算程序自动并行化！

另一方面，要真正完成一次并行计算，还必须进行通信、时序控制、程序生命期管理以及更高级的容错处理、计算节点动态增删等等工作，这些工作有些是跟特定计算任务紧密相关的，有些是跟特定计算任务无关的。而分层计算的目标就是将那些与“特定计算任务无关的”的工作分离出去完全由支撑环境来实现，从而使计算任务的编写者更专注于计算任务本身的编写！

如果拿分层计算跟MPI比较的话，我们以“计算节点动态增删”为例。在MPI平台下，这项工作首先要平台提供API支持（印象中MPI2.0支持），其次计算任务编程者要自己编写大量的代码来真正实现该功能（即使对于最简单的并行计算程序也不例外）。而在分层计算环境下，该工作将主要由支撑平台来实现，计算任务本身将仅需要很少的代码（对于简单的计算任务甚至不需要特别的代码），即可实现该功能！

希望上面这些描述能帮助你理解分层计算！

欢迎继续探讨！

--------------------------------------------------------------------------------
发件人: weiwei lin
发送时间: 2006年4月18日 10:24
主题: 回复： 答复: [博客园留言通知]关于分层计算

你在回复中说到：“而分层计算则力图尽量使计算任务的编程者从繁杂的通信控制、时序控制中解放出来，尤其是在面对一些具有良好的可分解/合并的计算任务时，计算任务的编程者甚至不需要考虑任何通信和时序的问题——这完全将由分层计算的支撑平台来处理！” 也就是说分层计算的容器负责这些主要的工作，而容器如何知道怎样分解/合成任务呢？如何实现（用户提交的）特定计算任务下的任何通信和时序呢？我想主要有两个实现途径：一、在用户提交任务（以普通程序）的同时用特定的语言（XML）编写“任务分解/合成的方案、任务通信模型”；二、在你的分层计算中，提供特定的语言，只要用户按照你的语言编写程序，那么分层计算容器就能从程序中分析出“任务分解/合成的方案、任务通信模型”，在该途径中，特定的语言是实现分层计算的关键而且应该是一种具有一定智能的语言。总之，用户总是很难摆脱要指出任务分解/合成、任务通信的复杂工作，除非能提供一种智能语言来编写并行计算程序！

很高兴能你与交流！

确实，如何分解计算任务是所有并行计算都需要面对的难点，分层计算也不例外。而我在考虑分层计算时，也不涉及降低计算任务分解本身的难度，而主要着眼于降低（注意是降低而非消除）计算任务本身（包括任务计算、任务分解以及结果合并）与其他因素（如通信、生命期维护等等）之间的耦合性，从而达到简化并行计算编程复杂度的目的。

我们知道，在MPI等平台下，进行并行程序开发时，需要编程者自己严格控制通信过程、以及控制各计算进程之间的先后时序，这就给计算任务的编写者带来了额外的要求！

而分层计算则力图尽量使计算任务的编程者从繁杂的通信控制、时序控制中解放出来，尤其是在面对一些具有良好的可分解/合并的计算任务时，计算任务的编程者甚至不需要考虑任何通信和时序的问题——这完全将由分层计算的支撑平台来处理！

需要指出的是，对于很多复杂的并行计算还无法完全不考虑时序控制的问题，这一点是目前分层计算需要进一步需要提供支持的方向。（但在我目前的项目计划中将不会深入考虑）

对于最后一个问题，在MPI平台下，资源利用效率的好坏几乎完全上依赖于计算任务的编写者；而在分层计算下，则很大程度依赖于整个支撑平台。换句话说，一个足够优秀的并行计算程序员在MPI平台下实现的程序资源利用效率应该高于分层计算——这就好比用汇编写的程序理论上应该高于C。

最后，由于本人在并行计算方面的实践经验相当匮乏，如果讨论中有什么错误请不吝赐教！

> -----邮件原件-----
> 发件人: linweiwei2004
> 发送时间: 2006年4月17日 13:19
> 主题: [博客园留言通知]关于分层计算
>
> 留言标题: 关于分层计算
> 留言内容:
> =====================================
> 我觉得分层计算实现的难点在如何分解计算任务，还有我想请问你：分层计算相对
> 于主/从计算范型或其他分布计算范型到底有什么优点？虽然你在文中提到“分布式存
> 储的大规模并行计算机具有并行程序设计难、不容易被用户所接受的缺点”等问题，
> 但是分层计算能解决这些问题吗？它相对于MPI等资源利用效率上有优势吗？
> =====================================
> 发送者: linweiwei

真厉害，九个月就能坐着洗脚了！佩服。

真厉害，九个月就能坐着洗脚了！佩服。

作得很好,如果预览能在同页面显示就好了。可否考虑用多页控件，把设置放在另一页。

呃……这是.NET 2.0吧，隐隐看到了范型……

希望能注明framework版本……

C#/VB的event是通过代码生成来解决这个问题的。你只要写下event定义，然后Add Handler和Remove Handler的活全部都是由编译器生成的，VB的话甚至连触发事件的代码都操办了。IL层面上看不出event有何可以消除重复代码的机制。有时候编译器代办是提高抽象性一大法宝。

如果.NET语言不帮你生成代码，仅仅提供给你为event书写add，remove过程的功能，那么就和不使用IMyObservable，直接把Attach, Detach, Notify写死在Subject类里的做法一样了。

没错呀，MyEventInvoker 需要去书写实现 IMyObservable 的代码，我想问这部分重复劳动有没技术手段避免？刚才我以为范型可以做到，其实不行。

@shensr

我有提到实现IObservable的简单方法：Default Adapter模式做的默认实现。大致代码如下：

public interface IMyObservable {
void Attach(IObserver observer);
void Detach(IObserver observer);
void Notify(EventArgs e);
}

public class DefaultMyObservable : IMyObservable {
private Dictionary<IMyObserver, object> observers = new Dictionary<IMyObserver, object>();

public void Attach(IObserver observer) {
...
}

public void Detach(IObserver observer) {
...
}

public void Notify(EventArgs e) {
...
}
}

public class MyEventInvoker : IMyObservable {
DefaultMyObservable observable = new DefaultMyObservable();

public void Attach(IObserver observer) {
this.observable.Attach(observer);
}

// 同上
...
}

刚才问有没什么技术手段复用实现 IObserverable 接口的代码，其实使用范型就可以了！

————————————
自己更正一下，范型解决不了这个问题！

Cavingdeep 兄提到应该使用 Aggregation/Composition 来避免 inheritance，这个我也同意，不过这样带来另一件事情——事件发布者需要实现 IObserverable 接口，这同样显得有点不爽。当然，如果这段实现代码可以通过某种技术手段复用的话，那就不成为问题了（我不知道现在有没有，AOP 中有没有这样的手段？）

回头再看 delegate，它不过就是一种类型，特殊一点罢了。而 event 呢，不过是在 delegate 基础上增加了一些使用限制（其实类似于 Property 对 Field 的限制）。

如果我们用 Observer 的思想来看 event 的话，一个对象声明了一个 event 就意味着它告诉别人“我是 IObserverable 的，不过不要直接 Attach/Detach 我，而应该 Attach/Detach 我的具体 event！”

不知大家是否同意我的上述描述？

换了块地方，二兄又开始交锋起来了；），不过从二位争论中我还真学了不少东西（比如Lambda Expression），太久不学习新东西了，落伍啦！

其实说到底，二兄争执的焦点并非技术，而在于对 ms 某些做法的看法。这个争论点我觉得没必要继续下去了，大家各自保留自己的看法就行。因为这个问题涉及到个人好恶，实在没办法说谁对谁错。

我建议大家还是回过头来再仔细比较一下使用 event 的方式和 Observer Pattern 的方式（其实也就是 interface 的方式，不知两位同意不？） 的优缺点、谁的OO特性更好一些、各自的适用场景……，当然我们应该假设，大家都支持 Anonymous Method/Class，这样比较公平一些。两位意下如何？

为什么老顾客们（包括你吗？）会被“逼”走呢？我真想不明白，有东西可学不是好事吗？是总觉得有被人拖着鼻子走的感觉吗？我怎么每次微软加入新功能都会兴奋异常呢？我感觉微软在为我的思维拓展空间，是我拼命想见到新特性而不是新特性拖着我鼻子。

我什么时候说Lambda Expression是动态特性？？

我也没有反对任何创新，只是不希望C#被搞得乌烟瘴气，直到把所有老顾客都逼走了才意识到自己该收敛一下了！

.NET是不可能复制JAVA的成功的，这世界上没有两样东西以同样的途径获得成功。JAVA这么成功，是抄谁的吗？不是，是靠创新。
只有一个法则能够获得成功，那就是不断创新。实践能够沉淀这些创新，创造经典，但不是手里捧着经典就能复现经典了，唯一要做的就是不断创新，直至其中一些成为经典。
你老是说，等到一种特性广为接受之后，或者说你想用的时候才去研究，否则就认为是花哨，乱改，没有目的性……其实我早就说了，没有人能够不研究和实现这些新特性，就发现他们的价值。你说这些不可靠，不能保护你的投资所以不去碰，其实是在等待别人实践和沉淀这些创新，总要有人做的，我就是其中一个。不然世界就会是一潭死水。
PS. Lambda Expression不是动态特性，而是Functional Programming的特性。。。

抛开别的不说，为什么一定要让C#实现Lambda Expression？我认为每种语言都有独到之处，如果我想用很高的灵活性，我就会去选择一种强的动态语言，比如Python, Ruby或者.NET下的Boo与IronPython，或许也可以考虑VB。作为任何一种编程语言一定要有它目的性，不可能随便乱来，什么特性都加进去。

现在.NET下就是微软老大，他说动就得动，试问有征求过我们真正使用者的意见吗，曾几何时？反观Java世界，民主性、通明性就是比.NET强很多，也这是在某个平台下选择长期开发的一个原因啊，不容忽视。假如什么时候微软说我们将不再支持.NET技术，而是已经转向XXX其他平台或概念那怎么办？这就同选择Email服务商一个道理，我绝对不会去选择一个在几年内就会变动的服务商，而是去选择像Yahoo!这样的公司，因为至少我两三年前的帐户还一直保留着，同样我的所有数据。对我来说Yahoo!甚至比我自己的硬盘更可靠。这才是真正吸引人的地方，你的东西再好，没过多长时间就变的话，换了是谁，都会信不过的。这就是为什么一开始大家都不敢用.NET做大项目而是用Java的真正原因！

Anonymous Class怎么进一步做Lambda Expression?
微软其实还是蛮有远见的
而且Delegate可以协变，可以按照参数类型和个数匹配（更进一步泛型化），灵活性是打不可低估的。而且CLR的IL中针对Delegate增加了很多新功能，目前C#还没有实现而已。

对，不容忽视的是Anonymous Method的确支持Closure，不过微软官方好像并没有提及这一点，不知道是什么原因？！如果基于这一点考虑，微软推出它，就是为了简化操作。

其实微软一开始就对delegate情有独中，偏偏不接受Java的基于interface的方案，搞得现在必须弄出一个Anonymous Method而不是Anonymous Class。个人还是觉得Anonymous Class使用起来比较爽。

而且我还看到
http：//www.sf.net/projects/jfunctional 上一个哥们用JAVA匿名类的Closure特性写了个FP类库，这是把匿名特性的抽象性挖出来的好例子。

我对Anonymous Method的理解有点不同，我认为它就是为了引入Closure而出现的，而不是为了简化事件处理（因为事件处理已经够简单的了）。有了Closure，就可以采用一些FP才有的思想写程序。而且你看Anonymous Method等到泛型出现才加入C#，因为Anonymous Method和泛型委托是天作之合。如果没有泛型，Anonymous Method真就没什么用了，也就是简化一下event。

使用Observer时不一定要继承Subject，有一条OO设计原则告诉我们要优先考虑Aggregation/Composition，而不是inheritance。所以你可以设计一个IObservable接口，拥有Attach、Notify等操作，然后用Default Adapter模式实现一个默认实现（即Subject类），在目标类中引用Subject类并且实现IObservable接口，用Delegation将Subject的实现用作接口的实现。

.NET中有一个类叫做System.ComponentModel.EventHandlerList，它的作用与Subject是一样的，用来存储delegate（IObserver）。.NET的设计原则告诉我们在事件较多的情况下考虑使用EventHandlerList来存储要被触发的delegates。

正因为要为不同的订阅者写不同的类拥有不同的实现太麻烦，所以Java下才多了个Anonymous Class这个syntax sugar（我想这是主要原因），但是.NET 2.0的Anonymous Method实际上也是这个原因才被实现的，因为每次都要写个方法来响应事件。

Cavingdeep和装配脑袋二兄，我刚刚另外写了一篇".Net event vs. observer Pattern"，现在大家可以换个地方讨论啦；）

http://shensr.cnblogs.com/archive/2005/11/28/286332.html

你理解成花哨，我却看到了抽象藏在背后。这每一种语言特性，都不是你第一眼看上去那个样子。你看我费了很大的心思研究泛型、运算符重载，创造出VBF那种与众不同的写程序的风格……都是我的嗜好。我一直在背后学习泛型设计和FP以从理论上指导我的想法。我希望让NET社区最先创造出最好的东西，而不是光借鉴JAVA的成功之处。

@Ninputer
不用讨论了，问题都清楚了，如何理解就看每个人了。一开始我就没说过用Observer做事件更容易，一开始是说谁最面向对象。

微软想与Java拼，所以出了.NET，微软想强Java的市场，它知道Java很保守，所以把.NET做的很花哨，包装的很好，以此来与Java竞争，这是不可争的事实。而事实又证明了“花哨”点的.NET的确有效，人们都很喜欢这种.NET下的便利，所以它越做越花哨，越做越夸张，如果不收敛一下恐怕就要走另一个极端了。这乃个人见解，纯属牢骚！:)

其实delegate并不是特别好用，只是很简单方便而已，微软知道它的客户都很懒，所以它很勤奋的为我们做着简化，不过所谓重口难调，很多高级用户并不买帐，他们希望的是在不影响能力的范围内做到最大程度的简化，不是只顾简化而使本来拥有的能力都丧失了，那就重蹈VB.NET的之前VB的覆辙了。

我没有混淆黑白，颠倒是非吧？
我最讲科学精神了，呵呵。

回到原点，我说你不讲科学精神是因为你说了

event只不过是.NET自圆其delegate的说所发明的副产物罢了。微软想用delegate做事件，又发现有一些“先天不足”，所以只好又创建了event这种副产物，微软比较习惯这样做。

但是，你举出这个论断的依据是不足的。你所说的delegate先天缺陷不是问题的本质。你所说的微软在发现delegate缺陷之后才设计event进行补救的说法是错误的。event和Observer的思想是一样的，只不过你所说的Observer是用接口-对象实现的，而event是用委托-方法实现的。

接下来我指出委托和接口本质上是一样的。所以你说的delegate天生的缺陷在接口上也存在，接下来就是我的分析（但是没能让你明白）。这里说接口实现也有缺陷是指“不用Observer“模式，使用裸字段保存接口的情况下所具有的缺陷 与 不使用event，直接使用delegate类型的裸字段所具有的缺陷是一样的。 而Observer模式解决了用裸字段的问题，event也解决了同样的问题。而使用裸变量来实现的“半Observer”是很少有人用的写法，因此实际没有人的代码有这个问题，所以你就没有理解我这个例子，没有理解我做对比的双方。我是比较一种假象的故意差劲的设计与没有event之前的delegate裸变量来进行比较，为的是说“裸delegate变量所固有的缺点”其实是普遍问题，event的设计是正确合理的。就这个意思，呼。提到泛型是因为delegate有这种思想在里面，这种思想确实有比接口高明的地方，所以用它来做event比用Interface设计成Observer模式更方便，所以用才delegate来实现。

所以我认为你不是从delegate/event或者Observer的抽象含义上去思考问题的，而是主观认为微软的设计一定都是有欠考虑的，所以才得出那个结论——这个过程是不科学的。

这句话可能说重了，我现在道歉。如果你有兴趣继续，我们从头开始讨论

@Ninputer
呵呵，误会，我说微软可不管你什么事，是你总喜欢为微软“擦屁股”（说的难听点儿），我最看不惯为明摆着的事实辩解的微软fans！我也是用.NET的，而且是不会转Java的，而且我告诉你我曾经是连任两届的微软MVP（.NET方面），不过我实事求是，我不辩解黑白，只是实事求是！一件事是什么样就把它说成什么样，我不会用各种方法去把它辩解成它本来不是的东西。

我经常说微软的“坏话”是为了不误导每一个.NET新手，他们有选择的权利，而且即使用花言巧语能够一时蒙蔽他们的双眼他们还是会在将来看破，而且看破后会更瞧不起微软，谁也不是傻子，没有必要欺骗，换句话说我是在维护.NET的长期利益！

注意所谓的坏话均属实，都是实话实说，.NET与Java一样，都是有利有弊，微软不能只说利不说弊也不能把不利的东西“点缀”成有利的东西，大家都是有目共睹的。

Ninputer大家都知道你是VB的大fans，微软的fans，只不过你太粉丝了你所说的话也就不可信了，至少我个人对你是这样看的，实话实说！^_^

我特别不想扯开话题，你为什么每讨论一句就给我扣一个帽子呢？
我想问问你把我说成“答非所问，遇到难题就大事化小，假装说成是你没有理解”，而且老是说微软XX,MSDN xx如何，怪不得你xx，就像是用微软来讽刺我一样，是希望达到一种什么目的呢，传播知识？授业解惑？

我的话如果你没有理解，是有我的错，但是你没有理解就是我表达很成问题吗？就是我没有能力阅读你的观点吗？为什么你理解错了我要背一堆缺点呢？

看来我要降低我的话地阅读标准了，你哑口无言也是正常，因为根本没听懂。。。

我的原话：如果用实现了某接口的对象裸字段来做……

这句话的意思是
interface ISomeInterface {...}

class SomeType
{
　　public ISomeInterface someField;
}

Encapsulate Field表示

class SomeType
{
　　private ISomeInterface someField;
　　public ISomeInterface APropery { get {return someField;} set{...}}
}

因为Encapsulate是封装的意思，所以没有封装之前叫做“裸”。我之所以举出这个例子是为了表达我使用“裸”字的原因

你的理解是
裸接口 = 标识接口 = 没有成员的接口

这不是我想表达的意思，我说刚才那堆话和例子是为了让你准确理解我的话。

明 白 了 吗？
（我的天，竟然需要这样解释，你不是故意的吧）

晕倒，看来你真得好好恶补一下表达与阅读了！如果一句话你不用明确的方式表达怎么期待听话的人能够准确地理解？我觉得任何做系统架构与设计资深的人都能够很自然地领略这一点，contract，就是要定义的毫无疑义！现在我知道难怪有时看MSDN看的我那么迷茫，原来是同一问题，表达的含含糊糊。不过这样也有好处，人家说你不对了你就可以从其他方面来解释，从此大事化小，小事化了，怎么说都不会是你自己错了，顶多就是“你没有理解我的意思”，或者“是我表达的不好”，高，领教了！

"Encapsulate Field"居然能被你翻译成“没有成员的接口”，真是搞得我哑口无言啊，最起码动词名词你总应该翻译正确吧，怎么翻译成了一个形容词加一个名词了？！

泛型和OO有个不同点就是约束建立在使用方还是定义方。OO是一种自顶向下的构造方式，设计来了以后要先考虑接口的设计，将对象所具有的共性抽象为接口。OO系统下的重构都是将变更上滤到需要变更的最高层次上再向下展开分散各种变更。调用对上发起方需要进行变更，都需要接受方对象体系从上到下展开改动。所以OO的设计模式都经过精心设计避免耦合，提高抽象，减少系统需要从顶向下的变更。
而泛型则是一种紧密堆砌的设计方式，任何一个调用对的发起方决定规则，接受方按照规则满足而拼装。发起方通过TypeTrait机制对接受方的特性进行抽象。我提出委托包含泛型思想，正是我思考的结果，不是我信口开河。

你不明白就是我错了吗？真有意思。更何况你是真的没听懂，晕。
委托就是接口，这句话的意思是，委托有和接口一样抽象意义，它继承了接口的思想又发展了这种思想。凡是了解Delegate的人，比如idior会非常同意我的话的。
再说你反驳的是什么？当你说苹果是水果时，是不是也要思考一下为什么水果可以是香蕉鸭梨而苹果就不可以呢，如果苹果是水果那么还要水果干吗？都吃苹果就好了。那个表情用的真是好呀，我就不重复使用了。

委托与接口决不是可以替代的关系，委托有比接口高明的地方，接口也还有委托所做不到的。你不承认动态语言有比静态语言高明的地方吗。我并没有说委托的一切都比接口更高明，很抱歉我没有在我的言论中强烈地体现出来这一点。

再说我说的“裸接口对象“是指public 字段，类型为某接口，就是接口类型的公共变量。我第一句提到“裸”时就是这样很清楚地描述的。为什么说“裸”，有种重构叫Encapsulate Field，是做什么用的，呵呵。你理解成“没有成员的接口“了吧，这次轮到我无言以对了。

@装配脑袋
晕，那我也来纠正你的回答，免得你误人子弟！:D

"委托就是接口"是错的，这太误人子弟了。单从实际的应用方面来讲，接口可以有多个方法，多个属性，多个事件等，而委托只不过有一个方法罢了。另一方面从逻辑角度讲，如果委托是接口，那么还要委托干吗，都用接口好了。:D

还有你说的Observer那块，除了一个“裸”字印象深刻外，其他的都没听懂，建议你换个词，裸啊裸的太不文明了，听着不舒服，你就翻译成“标识接口”之类的多好听啊，呵呵，当然只是个建议。

"委托比接口更高明……这就是委托的高明之处"。晕，对这段话简直无言以对，这就好像是说动态语言就是要比静态语言高明一样？！佩服佩服！

最后你矛盾的地方就是，你先是说委托就是接口，然后又说委托要比接口更高明，最后居然又说委托有泛型的思想！！听的我云里雾里稀里糊涂的，先是好像明白，然后越听越糊涂，最后是根本不明白了！一个字，强！

我并没有回答你的问题，我是在纠正你的回答。所以我不可能答非所问:)
“还有我好像没说一个东西如果是微软出的就不用科学的眼光去看了啊？你是听谁说的啊？ "
这分明是我说的，你当然没说。这是我对你前一个评论的评论，不是听别人说的哦

@装配脑袋
？？
？？？
晕，以前经常听说答非所问也是微软的一贯作风，今天算是领略到了。说的我晕乎乎的，有种“难道是我错了？”的感觉！:D

怎么听你说的都像是自相矛盾，难以自圆其说啊，说不通了就把话题扯远。还有我好像没说一个东西如果是微软出的就不用科学的眼光去看了啊？你是听谁说的啊？

Cavingdeep，委托就是接口。用委托做事件所有的先天不足接口都有，如果用实现了某接口的对象裸字段来做Observer，那么一切的一切都变成和用裸委托字段的情况一样。Observer中的设计避免了裸接口对象来做事件的弊端，event也做了同样的事情。但是，委托比接口更高明，它按照签名约束而接口则需要对象自己声明实现。方法不需要指定自己可以被哪种Delegate类型委托，只要签名符合即可；而对象即使包含接口所定义的全部成员，也必须声明实现才可以用那个接口来访问。这就是委托的高明之处，委托所体现的是泛型的思想。

不要一个东西是微软出的，就不用科学的眼光去看了。这样认识到的世界，不是真实的世界。

采用Observer模式做事件触发才是真正的面向对象的做法，event只不过是.NET自圆其delegate的说所发明的副产物罢了。微软想用delegate做事件，又发现有一些“先天不足”，所以只好又创建了event这种副产物，微软比较习惯这样做。

事实上“event更面向对象一些“某种意义上是正确的。event与纯粹的delegate变量的最大区别就是增加了封装性。让delegate的触发权完全由对象控制，而delegate所委托的实际函数则由订阅者决定。event就是要执行一种“什么时候发生我说了算，发生的时候做什么事你说了算“的效果。而纯粹的delegate变量则在可访问的范围内同时给与指定委托函数与触发的权限。

@shensr

呵呵，讲的很生动易理解，赞一下！^_^

同意event的解释 很形象 确实是为了限制事件只能由所有者触发 但外在的可以添加它触发后所引发的操作 但不能根本上把它重新指定

看了Cavingdeep的指正，真是幡然省悟，确实“半天的琢磨”太肤浅了，也没有认真查阅资料。之后痛改前非认真查看MSDN中的描述：

The delegate keyword is used to declare a reference type that can be used to encapsulate a named or an anonymous method.

The event keyword is used to specify an event. Events are used on classes and structs to notify objects of occurrences that may affect their state.


如Cavingdeep所述，delegate就是一种类型，而event是一个对象用来通知别的对象自己发生了某种事情（也就是表达对象事件里“事件”这一概念）。注意，在现实世界里，“事件”也只能由其所有者来触发。就好比我现在很疲劳，如果我不说（触发），那别人就不知道（我们假设疲劳不会有其他外在表现）。另一方面，由于是“我现在很疲劳”，显然如果由第三者来说（触发）的话，就很难具有真实性。注意，我们前面假定了疲劳不会有其他外在表现，否则你可以说疲劳完全可以通过情绪、工作状态等等来证实：）。也就是说，“我现在很疲劳”这个“事件”只能由我自己来触发才是真实和可靠的。

这样回过头来，我们就容易理解为什么event在声明它的Class之外只允许+=和-=操作。

那为什么event还不允许使用赋值操作呢？同样对于“我现在很疲劳”，我老板获知次消息后，可能会给我放假（遇到个好老板，哈哈）；我lp可能会给我煲汤……显然你也不会同意这样的事情：如果老板给我放了假，回家后lp一给我煲汤，老板放假的事情就自动取消了！

另外还有一个问题，规范的event都是如下格式：
xxxEventHandler(object sender, xxxEventArgs e);
为什么会有个sender呢？还是“我现在很疲劳”，我们把我看成员工类的一个实例，而老板处理员工疲劳事件的方法是固定的，这样“我”疲劳了，老板放我的假，张三疲劳了，老板放张三的假……为了区分是谁疲劳，就需要一个sender来标识了。

这样来解释event，不知大家同不同意？

从这个意义上来讲，我开始说event更加面向对象化也不算错误，不知Cavingdeep同意否：）

最后，非常感谢Cavingdeep兄的指正，原先的“琢磨”的确太肤浅。做学问真是来不得半点马虎啊；），等两天我重新整理一下，再重新写这篇东东，不过现在这个版本还是要保留下来。

赞,加油。