提示：本篇文章较长。虽然我选择了一个比较简单的操作符来在本文中实现，不过我们还是会遇到一些特例以及一些与LINQ相关的原则。因为我还在试着找出表现本文内容的最佳方式，所以本文的排版方式暂时是实验性的。

我们将要实现“Where”子句（也可以说是方法或操作符）。Where在总体上来说比较容易理解，但是涉及到延迟执行和流式处理的部分会有些麻烦。Where方法是泛型的，不过只有一个类型参数（在我看来这很重要，因为我觉得一个方法的泛型参数越多就越令人难以理解）。哦，对了，我们将在本文开始涉及查询表达式，这算是本文的一点额外猛料。
 

Where是什么？
 

Where有两个重载：
 

public static IEnumerable<TSource> Where( 

    this IEnumerable<TSource> source, 

    Func<TSource, bool> predicate) 

public static IEnumerable<TSource> Where( 

    this IEnumerable<TSource> source, 

    Func<TSource, int, bool> predicate)

在开始讲述Where方法到底做什么之前，我先指出几点LINQ操作符的常识，这些常识适用于几乎所有的LINQ操作符：
 

l LINQ操作符都是扩展方法 - 扩展方法要定义在顶层的，非嵌套的静态类型中而且其第一个参数要带有“this”修饰符。简单来说，扩展方法可以被其第一个参数的实例调用，就好像它是该参数类型的实例方法一样。

l LINQ操作符是泛型方法 - 我们要讲的Where操作符只有一个叫做TSource的类型参数，该类型参数指明了要处理的序列的类型。比如说，如果要处理一个string的序列，TSource就是string。

l LINQ操作符接受Func<...>这一族的泛型委托作为参数，通常以lamdba表达式的方式提供，不过委托的其他表现形式也都可以作为其参数。

l LINQ操作符处理序列。序列以IEnumerable<T>的形式出现，IEnumerable<T>中含有一个类型为IEnumerator<T>的迭代器。

我希望本文的读者对以上提及的概念有所了解，所以我就不再深入解释了。如果您对上述内容不够熟悉的话，请在继续读下去之前先去做些功课，否则接下来的内容将让您很难理解。

Where的目的是去过滤一个序列。它接受一个输入序列及一个谓词作为参数，返回一个结果序列。输出序列和输入序列的元素类型相同（也就是说如果输入是一个string的序列，输出也会是个string的序列），输出序列中只会包含输入序列中符合谓词条件的元素。（输入序列中的元素会依次被谓词检验。只有谓词返回true时，一个元素才会被包含在输出序列中。）

下面是关于Where的几个重要的细节：
 

l Where不会对输入序列做任何修改：它和List<T>.RemoveAll之类的方法不一样。

l Where是延迟执行的 - 在你开始读取输出序列中的元素之前，Where不会去输入序列中取元素。

l 不过也有一点不是延迟执行的，它会立即检查参数是否为null。

l 它以流式处理结果：它每次只处理一个结果元素，它把结果元素yield返回而且不会保留其引用。这意味着你可以把Where应用在一个无限长的序列上（比如说一个随机数的序列）。

l 你每在输出序列上迭代一次，Where方法就会在输入序列上迭代一次。

l 如果输出序列的迭代器被Dispose掉的话，对应的输入序列的迭代器也会被Dispose掉。（C#中的foreach语句会用try/finally来保障迭代器总是会被Dispose调，无论循环是因何种原因结束的。）

以上几点之中的有些对其它的操作符也适用。

Where的一个重载形式会接受一个Func<TSource, int, bool>作为参数，此重载让谓词中不仅可以访问元素值，还可以访问元素的index。Index总是从0开始并且每次递增1，无论之前谓词的结果如何。
 

我们要测试些什么？
 

理想情况下，我们要测试上述所有的东西。但是不幸的是，流式处理和序列被迭代多少次的细节测试起来很是麻烦。考虑到我们还要实现那么多的东西，我们以后再去测试那些。

我们来看看一些测试。首先，看一个“正向”测试 - 有一个整数数组，我们用一个lambda表达式来使得输出结果中仅包含小于4的元素。（“过滤”这个词无处不在，这真是很不幸。“过滤掉”这个说法比“包含”要好理解得多，但是实际上谓词就是以“正向”的方式来处理的。）
 

[Test] 

public void SimpleFiltering() 

{ 

    int[] source = { 1, 3, 4, 2, 8, 1 }; 

    var result = source.Where(x => x < 4); 

    result.AssertSequenceEqual(1, 3, 2, 1); 

}
 

虽然NUnit中已经有了CollectionAssert，我还是在用MoreLINQ中的TestExtension。有三个原因让我觉得MoreLINQ的扩展方法更好用：
 

l 扩展方法有助于减轻代码的混乱程度。

l 可以使用变长数组来表示期望的输出，这样更易于表达测试的意图。

l 断言失败的提示信息更清楚。
 

AssertSequenceEqual所做的事情看名字就可以猜出来，它检查输出序列（通常就是你调用AssertSequenceEqual方法时所使用的那个变量）和期望的序列（通常就是作为参数传入的变长数组）是否匹配。

目前为止进行的还不错。现在来看看参数校验吧：
 

[Test] 

public void NullSourceThrowsNullArgumentException() 

{ 

    IEnumerable<int> source = null; 

    Assert.Throws<ArgumentNullException>(() => source.Where(x => x > 5)); 

} 

[Test] 

public void NullPredicateThrowsNullArgumentException() 

{ 

    int[] source = { 1, 3, 7, 9, 10 }; 

    Func<int, bool> predicate = null; 

    Assert.Throws<ArgumentNullException>(()=> source.Where(predicate)); 

}
 

我就不再费劲去检查ArgumentNullException里面的参数名字了，但是我要测试参数是不是立即被校验的，这一点很重要的。我没有迭代输出结果，所以如果参数校验是延迟执行的，这两个测试将不能通过。

最后还有一个有趣的测试也是与延迟执行有关的。我们将用一个叫做ThrowingEnumerable的helper类来做这个测试，这个类是一个序列，你一旦迭代它，它就会抛出一个InvalidOperationException。这个测试是想要测试两点：
 

l 仅仅调用Where不会开始迭代输入序列。

l 调用GetEnumerator()来获取迭代器，然后再调用迭代器的MoveNext()的话，就开始迭代了，这就会导致一个异常被抛出。
 

对其它的操作符我们也需要做类似的测试，所以我在ThrowingEnumerable里写了一个helper方法：
 

internal static void AssertDeferred<T>( 

    Func<IEnumerable<int>, IEnumerable<T>> deferredFunction) 

{ 

    ThrowingEnumerable source = new ThrowingEnumerable(); 

    var result = deferredFunction(source); 

    using (var iterator = result.GetEnumerator()) 

    { 

        Assert.Throws<InvalidOperationException>(() => iterator.MoveNext()); 

    } 

}
 

现在我们就可以测试Where是不是延迟执行的了：
 

[Test] 

public void ExecutionIsDeferred() 

{ 

    ThrowingEnumerable.AssertDeferred(src => src.Where(x => x > 0)); 

}
 

以上所示的都是对Where的简单重载的测试，也就是那个谓词只能访问元素值而不能访问元素index的重载。能够访问index的那个重载的测试与上述测试非常类似。
 

来动手实现吧！
 

原版的LINQ to Objects能够通过所有这些测试，现在来实现我们自己的代码吧。我们将会用到迭代器代码块，它在C# 2中被引入来简化IEnumerable<T>的实现。如果你想了解更多的背景知识的话，我有几篇文章你可以去读一下...或者读C# in Depth（第一或第二版都可以）的第六章也可以。迭代器代码块让我们可以很简单的实现延迟执行...不过它也是一把双刃剑，我们马上就会体会到了。

Where的核心部分是这样的：
 

// Naive implementation 

public static IEnumerable<TSource> Where<TSource>( 

    this IEnumerable<TSource> source, 

    Func<TSource, bool> predicate) 

{ 

    foreach (TSource item in source) 

    { 

        if (predicate(item)) 

        { 

            yield return item; 

        } 

    } 

}
 

很简单，是吧？用迭代器代码块写出来的代码就和用自然语言描述起来差不多：迭代输入序列中的每一个元素，如果谓词在一个元素上返回true的话，这个元素就可以被yield（也就是包含）到输出序列中去。

诸位请看，有一些单元测试已经可以通过了。现在我们只需要参数校验了。参数校验很简单的，对吧？我们来试试看：
 

// Naive validation - broken! 

public static IEnumerable<TSource> Where<TSource>( 

    this IEnumerable<TSource> source, 

    Func<TSource, bool> predicate) 

{ 

    if (source == null) 

    { 

        throw new ArgumentNullException("source"); 

    } 

    if (predicate == null) 

    { 

        throw new ArgumentNullException("predicate"); 

    } 

    foreach (TSource item in source) 

    { 

        if (predicate(item)) 

        { 

            yield return item; 

        } 

    } 

}
 

呃。测试亮起了红灯，通不过，在“throw”的那一句上设断点也没用...断点根本就执行不到。怎么回事儿？

我之前已经给出过很明显的提示了。导致问题的就是延迟执行。在返回值被迭代之前，我们的代码不会被执行。我们的代码故意的没有去迭代返回值，所以参数校验也不会被执行。

我们遇到了一个C#设计上的缺陷。C#中的迭代器代码块不能很好的对“立即执行”（通常用来做参数校验）和“延迟执行”作出分离。我们必须得把我们上述的实现分为两个方法：第一个方法做参数校验，第二个方法含有迭代器代码块，用来实现延迟执行，第一个方法会调用第二个方法：
 

public static IEnumerable<TSource> Where<TSource>( 

    this IEnumerable<TSource> source, 

    Func<TSource, bool> predicate) 

{ 

    if (source == null) 

    { 

        throw new ArgumentNullException("source"); 

    } 

    if (predicate == null) 

    { 

        throw new ArgumentNullException("predicate"); 

    } 

    return WhereImpl(source, predicate); 

} 

private static IEnumerable<TSource> WhereImpl<TSource>( 

    this IEnumerable<TSource> source, 

    Func<TSource, bool> predicate) 

{ 

    foreach (TSource item in source) 

    { 

        if (predicate(item)) 

        { 

            yield return item; 

        } 

    } 

}
 

这样的代码很丑陋，但是能用：所有的针对于Where的简单重载（不含有index）的测试都可以通过了。有了现在的基础，要实现Where的含有index的重载也就很简单了：
 

public static IEnumerable<TSource> Where<TSource>( 

    this IEnumerable<TSource> source, 

    Func<T, int, bool> predicate) 

{ 

    if (source == null) 

    { 

        throw new ArgumentNullException("source"); 

    } 

    if (predicate == null) 

    { 

        throw new ArgumentNullException("predicate"); 

    } 

    return WhereImpl(source, predicate); 

} 

private static IEnumerable<TSource> WhereImpl<TSource>( 

    this IEnumerable<TSource> source, 

    Func<TSource, int, bool> predicate) 

{ 

    int index = 0; 

    foreach (TSource item in source) 

    { 

        if (predicate(item, index)) 

        { 

            yield return item; 

        } 

        index++; 

    } 

}
 

现在所有单元测试都通过了，我们的实现完成了。不过等一下...我们还没有无所不用其极的使用Where呢。
 

查询表达式
 

到目前为止，我们都是在直接的调用Where方法（尽管是以扩展方法的形式出现的），不过LINQ可是还给我们提供了查询表达式的。下面是“SimpleFiltering”那个测试的重写版本，其中用到了查询表达式：
 

[Test] 

public void QueryExpressionSimpleFiltering() 

{ 

    int[] source = { 1, 3, 4, 2, 8, 1 }; 

    var result = from x in source 

                 where x < 4 

                 select x; 

    result.AssertSequenceEqual(1, 3, 2, 1); 

}
 

（本博文中出现的方法名和下载到的代码中的不同，因为方法名中含有博客服务器的敏感词。呃。）

以上代码会和我们先前的测试产出完全相同的IL代码。编译器会把这种查询表达式的形式转译成调用方法的形式，并把用lambda表达式写出来的条件判断（x < 4）转换成一个委托。你可能会感到有点惊讶，因为我们还没有实现Select方法呢...不过我们现在用到的select投影操作实际上是不做任何事情的；我们并没有做任何真正的投影变换。这种情况下，只要查询表达式中含有任意其他的查询（上述代码中，这个查询就是Where）在内，编译器就会把“select”从句忽略掉，这样的话我们没有实现select也就无关紧要了。如果你把“select x”改写成“select x * 2”的话，将无法通过编译，因为我们的LINQ实现中只有Where。

查询表达式是基于上述这种模式的，这一强大的特性使得它极具灵活性。举例来说，LINQ to Rx就是基于这一点才能做到仅需实现对其应用场景有意义的操作符的。与此类似，C#编译器在处理查询表达式的时候并不需要知晓任何与IEnumerable<T>有关的东西，也正是如此，像IObservable<T>这样的完全与IEnumerable<T>无关的接口也可以得以应用。
 

我们学到了什么？
 

本文中有不少不太好理解的东西，其中与我们的实现和LINQ核心原则有关的是：
 

l LINQ to Objects是基于扩展方法，委托还有IEnumetable<T>的。

l 条件允许的话，LINQ操作符会尽量利用延迟执行和流式处理。

l LINQ操作符不会改变输入序列，而是会返回一个包含符合条件的元素的新序列。

l 查询表达式基于编译器对一些模式的解释；你要用到的查询表达式和哪些模式相关，你就只需要实现那些模式就可以了，无需多劳。

l 迭代器代码块很适合用来实现延迟执行...

l ...但是它也使得需要立即执行的参数校验变得很难搞。
 

代码下载
 

Linq-To-Objects-2.zip

很多人要求给本项目建一个源码管理服务器，这件事正在进行中；大概下一篇博文之前就可以完成。