对于上文的简化需求，使用Lambda表达式和内置的.NET 3.5扩展方法便可以写成这样：
- static List< int> EvenSquareLambda(IEnumerable< int> source)
- {
- return source.Where(i => i % 2 == 0).Select(i => i * i).ToList();
- }
.NET 3.5扩展方法的延迟效果
应该已经有许多朋友了解了.NET 3.5中处理集合时扩展方法具有“延迟”的效果，也就是说Where和Select中的委托（两个Lambda表达式）只有在调用ToList方法的时候才会执行。这是优点也是陷阱，在使用这些方法的时候我们还是需要了解这些方法的效果如何。不过这些方法其实都没有任何任何“取巧”之处，换句话说，它们的行为和我们正常思维的结果是一致的。如果您想得明白，能够自己写出类似的方法，或者能够“自圆其说”，十有八九也不会有什么偏差。但是如果您想不明白它们是如何构造的，还是通过实验来确定一下吧。实验的方式其实很简单，只要像我们之前验证“重复计算”陷阱那种方法就可以了，也就是观察委托的执行时机和顺序进行判断。
好，回到我们现在的问题。我们知道了“延迟”效果，我们知道了Where和Select会在ToList的时候才会进行处理。不过，它们的处理方式是什么样的，是像我们的“普通方法”那样“创建临时容器（如List< T>），并填充返回”吗？对于这点我们不多作分析，还是通过“观察委托执行的时机和顺序”来寻找答案。使用这种方式的关键，便是在委托执行时打印出一些信息。为此，我们需要这样一个Wrap方法（您自己做试验时也可以使用这个方法）：
- static Func< T, TResult> Wrap< T, TResult>(
- Func< T, TResult> func,
- string messgaeFormat)
- {
- return i =>
- {
- var result = func(i);
- Console.WriteLine(messgaeFormat, i, result);
- return result;
- };
- }
Wrap方法的目的是将一个Func< T, TResult>委托对象进行封装，并返回一个类型相同的委托对象。每次执行封装后的委托时，都会执行我们提供的委托对象，并根据我们传递的messageFormat格式化输出。例如：
- var wrapper = Wrap< int, int>(i => i + 1, "{0} + 1 = {1}");
- for (var i = 0; i < 3; i++) wrapper(i);
则会输出：
- 0 + 1 = 1
- 1 + 1 = 2
- 2 + 1 = 3
那么，我们下面这段代码会打印出什么内容呢？
- List< int> source = new List< int>();
- for (var i = 0; i < 10; i++) source.Add(i);
- var finalSource = source
- .Where(Wrap< int, bool>(i => i % 3 == 0, "{0} can be divided by 3? {1}"))
- .Select(Wrap< int, int>(i => i * i, "The square of {0} equals {1}."))
- .Where(Wrap< int, bool>(i => i % 2 == 0, "The result {0} can be devided by 2? {1}"));
- Console.WriteLine("===== Start =====");
- foreach (var item in finalSource)
- {
- Console.WriteLine("===== Print {0} =====", item);
- }
我们准备一个列表，其中包含0到9共十个元素，并将其进行Where…Select…Where的处理，您可以猜出经过foreach之后屏幕上的内容吗？
- ===== Start =====
- 0 can be divided by 3? True
- The square of 0 equals 0.
- The result 0 can be devided by 2? True
- ===== Print 0 =====
- 1 can be divided by 3? False
- 2 can be divided by 3? False
- 3 can be divided by 3? True
- The square of 3 equals 9.
- The result 9 can be devided by 2? False
- 4 can be divided by 3? False
- 5 can be divided by 3? False
- 6 can be divided by 3? True
- The square of 6 equals 36.
- The result 36 can be devided by 2? True
- ===== Print 36 =====
- 7 can be divided by 3? False
- 8 can be divided by 3? False
- 9 can be divided by 3? True
- The square of 9 equals 81.
- The result 81 can be devided by 2? False
列表中元素的执行顺序是这样的：
***个元素“0”经过Where…Select…Where，***被Print出来。
第二个元素“1”经过Where，中止。
第三个元素“2”经过Where，中止。
第四个元素“4”经过Where…Select…Where，中止。
……
.NET 3.5扩展方法的神奇之处
这说明了，我们使用.NET框架自带的Where或Select方法，最终的效果和上一节中的“合并循环”类似。因为，如果创建了临时容器保存元素的话，就会在***个Where中把所有元素都交由***个委托（i => i % 3 == 0）执行，然后再把过滤后的元素交给Select中的委托（i => i * i）执行。请注意，在这里“合并循环”的效果对外部是隐藏的，我们的代码似乎还是一步一步地处理集合。换句话说，我们使用“分解循环”的清晰方式，但获得了“合并循环”的高效实现。这就是.NET框架这些扩展方法的神奇之处1。
在我们进行具体的性能测试之前，我们再来想一下，这里出现了那么多IEnumerable对象实现了哪个GoF 23中的模式呢？枚举器？看到IEnumerable就说枚举器也太老生常谈了。其实这里同样用到了“装饰器”模式。每次Where或Select之后其实都是使用了一个新的IEnumerable对象来封装原有的对象，这样我们遍历新的枚举器时便会获得“装饰”后的效果。因此，以后如果有人问您“.NET框架中有哪些的装饰器模式的体现”，除了人人都知道的Stream之外，您还可以回答说“.NET 3.5中System.Linq.Enumerable类里的一些扩展方法”，多酷。
以上就介绍了.NET 3.5扩展方法和Lambda表达式实现的高性能分解循环的委托方法。
【编辑推荐】
