[C# 3.0 入门] [第一章 Lambda表达式] 第二节：Lambda表达式带来了什么

核心提示： List 6 List 5中对应的菜单项可是，这样的代码如果要为将来可能需要也可能不需要的变化准备的话，[C# 3.0 入门] [第一章 Lambda表达式] 第二节：Lambda表达式带来了什么(4)，将会变得相当臃肿，本质上完全没有意义的delegate和return显得非常刺眼，或许这种费

List 6 List 5中对应的菜单项

可是，这样的代码如果要为将来可能需要也可能不需要的变化准备的话，将会变得相当臃肿。本质上完全没有意义的delegate和return显得非常刺眼，看上去很难理解意图。这种代码就是YAGNI原则所说的那种应该避免的代码的典型例子。

因此，如果使用C# 2.0，这种code应该就不会被采用。笔者虽然属于那种对匿名方法使用得挥金如土的类型，在这个case上，（用匿名方法）恐怕优势要小于劣势。

然而，下面这并不是匿名方法，打眼一看就是较少的文字就能描述的Lambda表达式。下面的代码，“()=>true”和“()=>DateTime.Now.Hour > 19”，一看就是Lambda表达式的样子。

1private static MenuItemC[] MenuItems4 =
2　 {
3　　　 new MenuItemC("选择项1", 执行方法, ()=>true),
4　　　 new MenuItemC("选择项2", 执行方法, ()=>true),
5　　　 new MenuItemC("选择项3", 执行方法, ()=>true),
6　　　 new MenuItemC("选择项4", 执行方法, ()=>DateTime.Now.Hour >= 19),
7　 };
8

List 7 对List 6改用Lambda表达式后

说实话，code写成这样应该可以通过了。虽然违反了YAGNI的原则，但在不损害code的可理解性的范围内，对于未知修改来说也是上了保险了。

事实上这个保险也确实起作用。很快，菜单的有效时间从“19点以后”变成“19点后22点前”。来吧，数组做如下修正：

1private static MenuItemC[] MenuItems5 =
2　 {
3　　　 new MenuItemC("选择项1", 执行方法, ()=>true),
4　　　 new MenuItemC("选择项2", 执行方法, ()=>true),
5　　　 new MenuItemC("选择项3", 执行方法, ()=>true),
6　　　 new MenuItemC("选择项4", 执行方法,
7　　　　　　　　　　　 ()=>DateTime.Now.Hour >= 19 && DateTime.Now.Hour < 22),
8　 };
9

List 8 List 7中第四个菜单项的修改

这个变更，只用改写一个Lambda表达式这样的局部变更就能搞定，一瞬间的事。但是，如果采用最初的List 4的code，菜单项类还要加上结束时间，菜单的构建方法中还要加上判断，相当的费事。然而，不仅如此，如果不是Lambda表达式，而是使用匿名方法的前提下，或许这种费事的方法也会得到采用。总之，匿名方法与Lambda表达式的长度上的差别对code会有质的影响。