小菜鸟求赐教

Question

(1) sender表示触发事件的对象，比如当button1和button2的Click都关联给同一个事件处理函数的时候，可以通过sender区分点击了哪一个按钮。这在设计计算器这种程序的时候很有用，你只要为数字0~9的9个按钮编写一个函数就可以了。
(2) e表示参数，对于Click，它没什么用，但是另外一些事件就有用了，比如MouseMove事件，它当中有鼠标的当前位置；比如KeyPress，它包括了按了哪个键；比如FormClosing，它还可以传出参数，以决定是否要取消关闭窗口。
(3) => 表示Lambda表达式，它前面的括号相当于函数参数，后面的{}相当于一个函数体。

Answer 1

sender 翻译过来时  发送者，也就是事件的触发者。
e  代表事件的参数，具体事件的参数是不一样的。
可以理解成 使用指定的委托执行指定的方法吧。PS：个人观点，不喜勿喷。

Answer 2

http://www.cnblogs.com/shuai/archive/2010/09/19/1830836.html

Answer 3

Visual C#中Object sender,EventArgs e的含义  
http://pwcrab.blog.163.com/blog/static/1699038222010567125810/

Answer 4

你可以看做那些微软设计的控件的一个“事件模式代码”，它们的事件基本上都是 EventHandler 委托类型的（包括它的子类），因此全都有这类接口模式。不管你真的用得着还是用不着，都是这个接口。事件，你只是注册处理程序。事件的接口是在人家抛出事件的对象（类）中定义的，人家抛出事件的对象不会耦合你的程序所需要的接口定义，而是你的程序要求去了解人家事件定义接口。只有这样才能保证事件非常容易编程。

Answer 5

嗯，sorry，可能我说的有一些误解。微软设计的控件，事件定义除了是EventHandler委托类型以外，其它的基本上是与之完全一样的模式。比如说事件定义 public delegate void MouseButtonEventHandler(object sender, MouseButtonEventArgs e);
这里的 MouseButtonEventArgs  跟其它地方的 EventHandler 之类类型的参数放在同一个地方，这就是为了保证看上去一样。假设人家在 sender 之后、e之前定义一个别的参数，行不行？语法上完全可以。但是你使用这个事件时，就会感觉不再是跟其它事件类似的模式了。所以你觉得“几乎所有的事件都是（sener, eventhandler）”，这其实只是感觉，其实并没有制度（程序）保证。但是基本上微软的控件的所有事件都按这个模式手工定义的，而已。至于说起名字叫做sender、e，也一样是手工模式而已。如果人家不叫做sender，而叫做ctrol；或者参数不叫做e，而叫做arg，也完全可以。但是微软的控件基本上是“人治”地这样去保持一致性，没有任何语法上强迫这样去定义，但是人家在语义上保证了上万、上十万个定义中也是起相同的名字，让你容易联想和试用。

Answer 6

我们来多了解一些10几年前吹的很牛X的所谓《设计模式》，你会看到GOF不懂事件（而在微软的框架中可以追溯到vb1.0时代早就确立了事件模式标准了），因为它们四个人写出的“设计模式”，不但滥用了各接口概念，而且是方位完全是错误的。他们的模式，往往要求抛出事件者去耦合使用事件者的接口，抛出事件这需要把自己的对象实例传递给使用者的接口方法里。结果原本只需要1、2个模式的就能说清楚的东西，在《设计模式》这本书里却用又臭又长的将近20个模式去说，而且全都有雷人的名字，全都写了大篇奇怪的故事去说明。实际上搞懂事情驱动设计，可以避免被那些设计模式所累。

Answer 7

我觉得SP没必要总是在贬低设计模式，出设计模式的时候，也许还没有C#这样事件驱动的语言吧？？？况且，设计模式也不是什么坏东西，里面我觉得有一些思想在里面的还是