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會有質的影響。
