乱侃一通之：lamada表达式

可以不信，但不可全信^_^

 

lamada表达式,从本质上讲,无非是C#一些特性的组合,再加一点编译器的小魔法:

[1]扩展方法
这次让我看到了扩展方法不一样的地方,
让我没有想到的是,他不但作用在对象上,更重要的是能够在接口上也进行扩展
A:在这里,扩展方法是实施在IEnumerable接口上的(实际上还没有具体的类型存在)
B:扩展方法把调用的对象从参数中提取出来的,这个好象比A更重要,A还有可以通过别的途来实现
否则我们将写成:Enumerable.Select(i_s, s => s + 1);
实现前:IEnumerable ie = Enumerable.Select(i_s, s => s + 1);
实现后:IEnumerable ie = i_s.Select(s => s + 1);

 

[2]类型推导
废话不多说了,没有类型推导,我们将写成如下的样子
实现前:IEnumerable ie = i_s.Select <int,int>(s => s + 1);
实现后:IEnumerable ie = i_s.Select(s => s + 1);
类型推导还有一个副产品,就是VAR.

 

[3]闭包
这个才是关键中的关键,不想多说了,具体见我的另一个贴子:
http://topic.csdn.net/u/20090821/13/7c30e8cb-3d37-4d4f-9c11-0df1dd7be8f4.html
因为java没能实现闭包,而C#在2.0时实现的,所以说java永远实施不了LINQ
简单点说,如果没有闭包,将不会有lamada表达式的传递性写法.

 

[4]匿名方法
需要使用委托delegate,并传入方法
实现前:ie = i_s.Select(new Func <int,int>(delegate(int i){return i+1;}));
实现后:IEnumerable ie = i_s.Select(s => s + 1);

 

[5]泛型
这个就不多说了

 

[6]编译器魔法
A:编译器自动生成的_SelectIterator_d__d <TSource, TResult>对象
B:C#3.0中的简写:s=>s+1,得益于类型识别,省了(),return {},看上去清爽多了

 

[7]其它
其它应该没有了吧,
有的话请你补充.

总结一下:
[1]一定是基于集合类型的操作,实现了:IEnumerable
[2]表达式被编译器转换成委托和静态扩展方法。
[3]执行扩展方法的返回一个实现了IEnumerable <T> 接口的"编译器自动生成类型"对象。
[4]这个"对象"传递了"数据源"，以及委托方法的引用。
[5]一切尽在代码中....