博客园_my diary

自己动手重新实现LINQ to Objects: 11 - First，Last，Single以及它们带有OrDefault的重载

2012-04-09T04:54:00Z

本文翻译自Jon Skeet的系列博文“Edulinq”。

本篇原文地址：

http://msmvps.com/blogs/jon_skeet/archive/2010/12/29/reimplementing-linq-to-objects-part-11-first-single-last-and-the-ordefault-versions.aspx

今天我实现了六个操作符，每个操作符都有两个重载。我一开始以为这些操作符的实现会很相似，但是最后发现每个都稍微有些不同...

今天实现了哪些操作符？

以下三个集合的排列{First, Last, Single}, {带有/不带有OrDefault }, {带有/不带有谓词}，其结果是十二个不同的方法签名：

public static TSource First<TSource>(
this IEnumerable<TSource> source)

public static TSource First<TSource>(
this IEnumerable<TSource> source,
Func<TSource, bool> predicate)

public static TSource FirstOrDefault<TSource>(
this IEnumerable<TSource> source)

public static TSource FirstOrDefault<TSource>(
this IEnumerable<TSource> source,
Func<TSource, bool> predicate)

public static TSource Last<TSource>(
this IEnumerable<TSource> source)

public static TSource Last<TSource>(
this IEnumerable<TSource> source,
Func<TSource, bool> predicate)

public static TSource LastOrDefault<TSource>(
this IEnumerable<TSource> source)

public static TSource LastOrDefault<TSource>(
this IEnumerable<TSource> source,
Func<TSource, bool> predicate)

public static TSource Single<TSource>(
this IEnumerable<TSource> source)

public static TSource Single<TSource>(
this IEnumerable<TSource> source,
Func<TSource, bool> predicate)

public static TSource SingleOrDefault<TSource>(
this IEnumerable<TSource> source)

public static TSource SingleOrDefault<TSource>(
this IEnumerable<TSource> source,
Func<TSource, bool> predicate)

这些操作符有以下的共同点：

l 它们都是接受一个泛型参数的扩展方法

l 它们都是立即执行的

l 他们都会检查参数是否为null

l 这些操作符的接受谓词的重载和以下形式等价：source.Where(谓词).该操作符()。换句话说，这些接受谓词的重载就是在执行操作符之前过滤一下

了解了上面这几点之后，对于每个操作符就只需考虑三种可能性：在谓词执行之后（如果有谓词的话），如果源序列是空的怎么处理？源序列只包含一个元素怎么处理？如果源序列包含多个元素如何处理？我们可以用一个简单的表来描述上述问题的结果：

操作符	如果源序列是空的	源序列只包含一个元素	源序列包含多个元素
First	抛异常	返回该元素	返回第一个元素
FirstOrDefault	返回default(TSource)	返回该元素	返回第一个元素
Last	抛异常	返回该元素	返回最后一个元素
LastOrDefault	返回default(TSource)	返回该元素	返回最后一个元素
Single	抛异常	返回该元素	抛异常
SingleOrDefault	返回default(TSource)	返回该元素	抛异常

很明显，如果输入序列只有一个元素的话，这几个操作符的执行结果是非常一致的:) 类似的，如果输入的序列是空的的话，那么没有“OrDefault”的操作符会抛异常（InvalidOperationException），而带有“OrDefault”的操作符则会返回元素类型的默认值（引用类型的默认值为null，int的默认值为0，等等）。

如果（可能是被过滤过的）输入序列含有多个元素的话，那这些操作符的执行结果的差异是很大的，First和Last的结果是顾名思义的，而Single抛出异常。值得注意的是，SingleOrDefault也会抛出异常，因为它要做的事又不是像这样：如果输入序列只有一个元素的话，返回该元素，否则的话返回默认值。如果你需要能够处理多元素序列的操作符的话，用First或Last。如果你需要处理可能为空的序列的话，使用FirstOrDefault或LastOrDefault。请注意，如果使用带有“OrDefault”的操作符的话，那么一个空的序列和一个仅包含默认值的序列的执行结果会是完全一样的。我们稍后会提到DefaultIfEmpty。

现在我们知道这些操作符做什么了，我们来开始测试吧。

我们要测试什么？

今天早晨，我发了一条推文说我在开始实现之前就写了72个测试用例。实际上，我最终写了80个，为什么写了80我们稍后会说。对每一个操作符，我测试了12个用例：

l 源序列是否为null的测试（没有谓词的重载）

l 源序列是否为null的测试（有谓词的重载）

l 谓词是否为null的测试

l 源序列不包含元素的测试（没有谓词的重载）

l 源序列不包含元素的测试（有谓词的重载）

l 源序列只包含一个元素的测试（没有谓词的重载）

l 源序列只包含一个元素，且该元素符合谓词的测试

l 源序列只包含一个元素，且该元素不符合谓词的测试

l 源序列包含多个元素的测试（没有谓词的重载）

l 源序列包含多个元素且只有一个元素符合谓词的测试

l 源序列包含多个元素且多个元素符合谓词的测试

实现这些测试用例时，我做了很多复制粘贴，每个操作符的测试用例用的都是同一组数据，只是预期的结果值不同。

另外，First和FirstOrDefault分别有两个额外的测试，Last和LastOrDefault也分别有两个：

l First和FirstOrDefault：当没有谓词的时候，这两个方法应该在遇到第一个元素时就立刻返回，不应该继续遍历序列的剩余部分

l First和FirstOrDefault：当有谓词的时候，应该在找到第一个符合谓词的元素时就立刻返回

l Last和LastOrDefault：当源序列实现了IList<T>且没有谓词时，这两个方法使用源序列的Count属性和索引器去访问最后一个元素，这是一个特殊优化

l Last和LastOrDefault：当源序列实现了IList<T>且有谓词的时候，则没有上述的优化。这种情况下，这两个方法要彻底遍历整个源序列

上面提到的后两个测试用到了一个叫做NonEnumerableList的新集合类型，这个类型的所有方法实现都依赖于一个List<T>，除了GetEnumerator方法（泛型的和非泛型的）之外，这两个方法仅仅是抛出NotSupportedException异常。这一点对于测试上述的优化很有帮助，有关优化的问题我们说到的时候再谈。

来动手实现吧！

这几个操作符的实现比我预期的要有趣，所以我下面要把十二个方法实现都列出来。这些方法可不是复制粘贴一下了事的，参数验证的部分除外。

如果我们基于Where和没有谓词的重载来实现有谓词的重载，并且基于DefaultIfEmpty和名字中不含Default的重载来实现名字中含有Default的重载的话，那么我们就只需要实现三个没有谓词和名字里没有Default的方法。但是，就像我之前说过的那样，单独的实现每个操作符会有一些好处。

为了避免看起来冗余，我把每个方法中的参数检验的部分省略掉了。不过在真实的代码中是含有参数检验的。我们从First开始吧：

public static TSource First<TSource>(
this IEnumerable<TSource> source)
{
// Argument validation elided
using (IEnumerator<TSource> iterator = source.GetEnumerator())
{
if (iterator.MoveNext())
{
return iterator.Current;
}
throw new InvalidOperationException("Sequence was empty");
}
}

public static TSource First<TSource>(
this IEnumerable<TSource> source,
Func<TSource, bool> predicate)
{
// Argument validation elided
foreach (TSource item in source)
{
if (predicate(item))
{
return item;
}
}
throw new InvalidOperationException("No items matched the predicate");
}

这两个实现看起来差异很大，这是我有意为之的。对于没有谓词的重载，我也可以用foreach来实现的，就从foreach的循环体中无条件的返回就可以了。然而，我想要强调我们在First中不需要循环遍历。我们只需要移向第一个元素，然后返回就可以了，如果无法移向第一个元素则抛出异常。没有任何迹象显示我们会再次调用MoveNext。而对于有谓词的重载，我们必须一直循环遍历直到找到一个符合谓词的元素，我们只在遍历完所有元素而找不到符合谓词的元素时才抛出异常。

下面我们来看看当序列为空时如何返回默认值：

public static TSource FirstOrDefault<TSource>(
this IEnumerable<TSource> source)
{
// Argument validation elided
using (IEnumerator<TSource> iterator = source.GetEnumerator())
{
return iterator.MoveNext() ? iterator.Current : default(TSource);
}
}

public static TSource FirstOrDefault<TSource>(
this IEnumerable<TSource> source,
Func<TSource, bool> predicate)
{
// Argument validation elided
foreach (TSource item in source)
{
if (predicate(item))
{
return item;
}
}
return default(TSource);
}

这个有谓词的FirstOrDefault看起来和有谓词的First非常相似，但是没有谓词的FirstOrDefault和没有谓词的First却有点细微的差别：我们在这里没有用if语句而是用了三元运算符（虽然说用if也是完全可以的）。不管能否移向第一个元素，我们都需要返回值。如果三元运算符允许第二个或第三个操作对象为throw语句就好了，但是即使不能的话也不是什么大问题。

接下来我们来实现Single，它在某些方面与First的相似性比Last与First的相似性更大：

public static TSource Single<TSource>(
this IEnumerable<TSource> source)
{
// Argument validation elided
using (IEnumerator<TSource> iterator = source.GetEnumerator())
{
if (!iterator.MoveNext())
{
throw new InvalidOperationException("Sequence was empty");
}
TSource ret = iterator.Current;
if (iterator.MoveNext())
{
throw new InvalidOperationException("Sequence contained multiple elements");
}
return ret;
}
}

public static TSource Single<TSource>(
this IEnumerable<TSource> source,
Func<TSource, bool> predicate)
{
// Argument validation elided
TSource ret = default(TSource);
bool foundAny = false;
foreach (TSource item in source)
{
if (predicate(item))
{
if (foundAny)
{
throw new InvalidOperationException("Sequence contained multiple matching elements");
}
foundAny = true;
ret = item;
}
}
if (!foundAny)
{
throw new InvalidOperationException("No items matched the predicate");
}
return ret;
}

这个比First复杂多了。没有谓词的重载的开头和First的开头一样，不同的是如果能够成功的移向第一个元素的话，我们需要记住第一个元素的值（因为我们可能需要返回该值）然后试着移向第二个元素。如果可以移向第二个元素，就要抛出异常，如果不能移向第二个元素，那就可以返回刚才记录下的值。

有谓词的重载更麻烦。我们依然需要记住第一个找到的符合谓词的值，不过因为这次我们在循环，我们还需要记住是否已经找到过一个符合谓词的值了。如果能够找到第二个符合谓词的值，就必须抛异常。如果一个符合谓词的值都找不到，也要抛异常。请注意，尽管我们给ret赋了一个default(TSource)的初值，但是我们的return语句执行时ret肯定不会是初值的状态。然而，C#的明确赋值的语法无法理解这一点，所以我们需要给ret一个“傀儡”式的初值，而default(T)是唯一可以用的值。有另外一种不用foreach的实现方法：遍历序列直到找到第一个符合谓词的元素，此时声明一个局部变量并且把找到的元素赋值给该变量，然后再开始另一个循环，以确保不能再找到其他符合谓词的值了。我个人觉得这种方式太复杂了，所以我选择了用foreach的方式。

下面实现SingleOrDefault的两个重载，这两个重载之间的差别就不是那么大了：

public static TSource SingleOrDefault<TSource>(
this IEnumerable<TSource> source)
{
// Argument validation elided
using (IEnumerator<TSource> iterator = source.GetEnumerator())
{
if (!iterator.MoveNext())
{
return default(TSource);
}
TSource ret = iterator.Current;
if (iterator.MoveNext())
{
throw new InvalidOperationException("Sequence contained multiple elements");
}
return ret;
}
}

public static TSource SingleOrDefault<TSource>(
this IEnumerable<TSource> source,
Func<TSource, bool> predicate)
{
// Argument validation elided
TSource ret = default(TSource);
bool foundAny = false;
foreach (TSource item in source)
{
if (predicate(item))
{
if (foundAny)
{
throw new InvalidOperationException("Sequence contained multiple matching elements");
}
foundAny = true;
ret = item;
}
}
return ret;
}

这次我们只是把没有谓词的重载里的throw语句替换成了return语句，并且在有谓词的重载中移除了没有找到符合谓词的元素的判断。我们在这里给ret赋以初值是有好处的，因为如果后面的代码不会给ret赋以其他值，那么ret已经有了正确的返回值了。

下一个是Last：

public static TSource Last<TSource>(
this IEnumerable<TSource> source)
{
// Argument validation elided
IList<TSource> list = source as IList<TSource>;
if (list != null)
{
if (list.Count == 0)
{
throw new InvalidOperationException("Sequence was empty");
}
return list[list.Count - 1];
}

using (IEnumerator<TSource> iterator = source.GetEnumerator())
{
if (!iterator.MoveNext())
{
throw new InvalidOperationException("Sequence was empty");
}
TSource last = iterator.Current;
while (iterator.MoveNext())
{
last = iterator.Current;
}
return last;
}
}

public static TSource Last<TSource>(
this IEnumerable<TSource> source,
Func<TSource, bool> predicate)
{
// Argument validation elided
bool foundAny = false;
TSource last = default(TSource);
foreach (TSource item in source)
{
if (predicate(item))
{
foundAny = true;
last = item;
}
}
if (!foundAny)
{
throw new InvalidOperationException("No items matched the predicate");
}
return last;
}

我们从没有谓词的方法开头的优化谈起吧。如果输入序列是个列表的话，我们可以获取列表的元素数量，然后根据元素数量的不同，或者是抛出异常或者是返回索引最大的元素。如果还要再优化一点的话，我可以把Count值存到一个局部变量里，但是我假设获取IList<T>的Count的代价是很低的。如果有哪位对这一点持反对意见，我很愿意做出修改：）请注意，我还假设了另一个情况，实现IList<T>的类型含有的元素不会超过Int32.MaxValue，否则的话，这个优化就会失败。

如果不做优化的话，我们可以遍历整个序列，每次迭代都用最新访问到的元素来更新一个局部变量的值。我在这里没有用foreach，但是并没有什么特别的原因--我们其实也可以用foreach，每次的迭代都把一个叫做foundAny的变量设为true，然后在最后测试foundAny的值。实际上，上面所描述的就正是有谓词的方法所采用的方式。不许得承认，采用这个方式在一定程度上是不得已而为之--我们不能调用MoveNext然后把获取到的值存起来，因为这个值有可能不符合谓词的约束。

Last的有谓词的重载没有优化，这是LINQ to Objects（官方实现）的做法，但是我不知道这么做的原因。我们可以利用索引器来从后向前反向遍历。有一个可能的解释是：谓词在处理某些值时有可能会抛出异常，如果我们在处理实现了IList<T>的序列的时候直接跳到序列尾部的话，就会造成可观察的差别。我很想知道这是不是真的原因--如果哪位能够提供内部信息的话，我会更新这篇博文。

现在，我们就只有一个操作符需要实现了--LastOrDefault：

public static TSource LastOrDefault<TSource>(
this IEnumerable<TSource> source)
{
// Argument validation elided
IList<TSource> list = source as IList<TSource>;
if (list != null)
{
return list.Count == 0 ? default(TSource) : list[list.Count - 1];
}

TSource last = default(TSource);
foreach (TSource item in source)
{
last = item;
}
return last;
}

public static TSource LastOrDefault<TSource>(
this IEnumerable<TSource> source,
Func<TSource, bool> predicate)
{
// Argument validation elided
TSource last = default(TSource);
foreach (TSource item in source)
{
if (predicate(item))
{
last = item;
}
}
return last;
}

除了优化的部分，有谓词的和没有谓词的方法看起来很相似...比其他操作符的两个重载之间的差异要小。两个重载中，我们都是先定义一个返回值，并赋值为default(TSource)，然后遍历整个序列，并更新返回值，如果有谓词的话，就仅当元素符合谓词时才更新返回值。

结论

我今早起床时没料到这篇博文会写的这么长，不过我希望上述的各个实现之间的差异和"Last/LastOrDefault"没有优化的怪事能够值得这么多的辛苦。

虽然前面提到了DefaultIfEmpty，但是我准备下次再实现它。虽然说如果今晚抓紧的话，还是可以做完的...

附录

我发现在LINQ to Objects（官方实现）中，Single和SingleOrDefault没有谓词的重载在遇到第二个元素时马上就会抛出异常。但是有谓词的重载即使遇到了第二个元素，还是会继续遍历。这看起来很是荒唐，没有连贯性。我发了一个Connect issue，我们看看会有怎样的答复。

本文链接

自己动手重新实现LINQ to Objects: 10 - Any和All

2012-02-15T05:35:00Z

本文翻译自Jon Skeet的系列博文“Edulinq”。

本篇原文地址：

http://msmvps.com/blogs/jon_skeet/archive/2010/12/28/reimplementing-linq-to-objects-part-10-any-and-all.aspx

今天我们介绍两个操作符：Any和All。

Any和All做什么？

Any有两个重载，而All只有一个：

public static bool Any<TSource>(

this IEnumerable<TSource> source)

public static bool Any<TSource>(

this IEnumerable<TSource> source,

Func<TSource, bool> predicate)

public static bool All<TSource>(

this IEnumerable<TSource> source,

Func<TSource, bool> predicate)

这两个方法所做的事情完全可以顾名思义：

l 不接受谓词的Any用于判断输入序列中是否存在任何元素

l 接受谓词的Any用于判断输入序列中是否存在能够通过谓词检验的元素

l All用于判断输入序列中的元素是否全部都能通过谓词的检验

这两个操作符都是立即执行的，它们在得出最终结果之前不会返回。

很重要的一点，All必须要迭代整个输入序列才能返回true，但是它只要遇到一个不能通过谓词检验的元素就会返回false；而Any只要找到一个可以通过谓词检验的元素就会返回true，但是必须要迭代整个输入序列才能返回false。这就引出了一个很简单的LINQ性能小窍门，下面这种用法几乎在所有情况下都是不可取的：

// Don't use this

if (query.Count() != 0)

上面的用法会迭代整个输入序列，如果你只想知道序列中是否含有元素的话，这样来做：

// Use this instead

if (query.Any())

如果这是一个较大的LINQ to SQL查询中的一部分，那么这两种做法的区别可能不大，但是对于LINQ to Objects来说，区别很大。

我们需要测试什么？

我今晚感觉不错，我甚至把参数校验都做了...虽然说参数校验在这个立即执行的特例下并不困难。

除此之外，我还测试了以下一些场景：

l Any作用于空序列应该返回false，而All则应该返回true。（因为无论谓词是什么样的，没有任何一个元素会通不过检验。）

l 一个序列，只要它含有元素，不接受谓词的Any就应该返回true。

l 如果所有元素都不能通过谓词，那么Any和All都应该返回false。

l 如果部分元素能够通过谓词，Any将会返回true而All会返回false。

l 如果所有元素都能够通过谓词，那么All会返回true。

以上测试都很简洁明了，我就不给出代码了。还有最后一个测试很有趣：我们要证明Any会在找到第一个符合条件的元素之后立即返回，证明的手段是通过把Any作用在一个被完整迭代时会抛出异常的查询结果上。最简单的方式就是创建一个包含有0的整数序列，然后对其做Select操作，Select中会把每一个元素除以某个常数。以下的测试用例中，序列中会导致异常的元素之前存在一个能够通过谓词的元素：

[Test]

public void SequenceIsNotEvaluatedAfterFirstMatch()

{

int[] src = { 10, 2, 0, 3 };

var query = src.Select(x => 10 / x);

// This will finish at the second element (x = 2, so 10/x = 5)

// It won't evaluate 10/0, which would throw an exception

Assert.IsTrue(query.Any(y => y > 2));

}

对于All，也有一个类似的测试用例，其中会导致异常的元素前面存在一个不能通过谓词检验的元素。

现在所有测试都有了，下面开始有趣的部分了：

来动手实现吧！

有一点需要提醒，我们可以基于接受谓词的Any或者基于All来实现另外两个方法。比如说，如果已经实现了All的话，那么Any就可以这样实现：

public static bool Any<TSource>(

this IEnumerable<TSource> source)

{

return source.Any(x => true);

}

public static bool Any<TSource>(

this IEnumerable<TSource> source,

Func<TSource, bool> predicate)

{

if (predicate == null)

{

throw new ArgumentNullException("predicate");

}

return !source.All(x => !predicate(x));

}

基于接受谓词的的Any来实现不接受谓词的Any是最简单的，我们使用了一个对任何元素都会返回true的谓词，这就意味着只要输出序列中含有元素就会返回true，这正是我们想要的行为。

上面调用All时的两次否操作会让你费点脑筋，不过这其实就是德摩根定律在LINQ中的表现形式：我们对谓词做否操作，来检验是否所有的元素都不能通过谓词，得到结果后，再次做否操作并返回。由于否操作的原因，这种实现方式仍然会在合适的情况下提前返回。

虽然以上的方式可行，但是我更喜欢给每个方法一个单独的实现，这样做简单明了：

public static bool Any<TSource>(

this IEnumerable<TSource> source)

{

if (source == null)

{

throw new ArgumentNullException("source");

}

using (IEnumerator<TSource> iterator = source.GetEnumerator())

{

return iterator.MoveNext();

}

}

public static bool Any<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))

{

return true;

}

}

return false;

}

public static bool All<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))

{

return false;

}

}

return true;

}

这样的实现方式很明显的凸显了“提前返回”这一特性。而且，这样做也可以使得堆栈跟踪记录更易读。对于一个下游开发者来说，如果调试Any时在堆栈跟踪记录中看到了调用All的记录会显得很奇怪；调用All时看到了Any也会很奇怪。

有一点很有趣，不接受谓词的Any中我们没用到foreach。而是用了迭代器第一次调用MoveNext方法时的返回值来表示序列中是否存在元素。读这个方法可以很明显的（至少对我来说很明显）看出我们根本不关心第一个元素的值是什么，因为我们根本就没有去访问它。

结论

尽量使用Any而不是Count的建议或许是这篇文章中最重要的一点，余下的部分都比较简单，不过能基于一个操作符来实现另一个操作符总是很有趣的。

下一篇讲什么呢？或许是Single、SingleOrDefault、First、FirstOrDefault、Last或者LastOrDefault。也或许我会把它们都放到一篇文章中来阐释它们的相似同时也强调它们之间的差别。

本文链接

自己动手重新实现LINQ to Objects: 9 - SelectMany

2011-12-15T15:28:00Z

本文翻译自Jon Skeet的系列博文“Edulinq”。

本篇原文地址：

http://msmvps.com/blogs/jon_skeet/archive/2010/12/27/reimplementing-linq-to-objects-part-9-selectmany.aspx

我们接下来要实现的这个操作符是LINQ中最重要的操作符。大多数（或者是全部？）其他的返回一个序列的操作符都可以通过调用SelectMany来实现，这是后话按下不表。现在我们首先来实现它吧。

SelectMany是什么？

SelectMany有四个重载，看起来一个比一个吓人：

public static IEnumerable<TResult> SelectMany<TSource, TResult>(

this IEnumerable<TSource> source,

Func<TSource, IEnumerable<TResult>> selector)

public static IEnumerable<TResult> SelectMany<TSource, TResult>(

this IEnumerable<TSource> source,

Func<TSource, int, IEnumerable<TResult>> selector)

public static IEnumerable<TResult> SelectMany<TSource, TCollection, TResult>(

this IEnumerable<TSource> source,

Func<TSource, IEnumerable<TCollection>> collectionSelector,

Func<TSource, TCollection, TResult> resultSelector)

public static IEnumerable<TResult> SelectMany<TSource, TCollection, TResult>(

this IEnumerable<TSource> source,

Func<TSource, int, IEnumerable<TCollection>> collectionSelector,

Func<TSource, TCollection, TResult> resultSelector)

其实还不算太坏，这些重载只是同一个操作的不同形式而已。

无论是哪个重载，都需要一个输入序列。然后用一个委托来处理输入序列中的每个元素以生成一个子序列，这个委托可能会接受一个代表元素index的参数。

再然后，我们或者把每个子序列中的元素直接返回，或者再用另一个委托来做处理，这个委托接受输入序列中的元素并接受其对应的子序列中的元素。

以我的经验来说，使用index两个重载不太常用，而另外两个重载（上面列出的第一个和第三个）则比较常用。还有，当C#编译器处理一个含有多个from子句的查询表达式的时候，它会把出第一个from之外的其他from子句转译为上面的第三个重载。

为了把上面的说法放入实例中理解，我们假设有这样一个查询表达式：

var query = from file in Directory.GetFiles("logs")

from line in File.ReadLines(file)

select Path.GetFileName(file) + ": " + line;

上面的查询表达式会被转译为下面的“正常”调用：

var query = Directory.GetFiles("logs")

.SelectMany(file => File.ReadLines(file),

(file, line) => Path.GetFileName(file) + ": " + line);

这个例子中，编译器会把表达式中的select子句转译为投影操作；如果表达式后面还跟有where子句或其他子句，编译器会把file和line包装在一个匿名类型中传递给投影操作。这是查询表达式转译中最令人难理解的一点，因为这涉及到了透明标识符（transparent identifiers）。就现在来说，我们只分析上面给出的简单例子。

上例中的SelectMany接受三个参数：

l 输入序列，也就是一个字符串序列（Directory.GetFiles所返回的文件名）

l 一个初始投影操作，它把一个文件名转化为该文件中包含的一行行的字符串

l 一个结束投影操作，它把一个文件名和一行文件内容转化为一个由冒号分隔的字符串

表达式的最后结果会是一个字符串的序列，其中包含所有log文件的每一行，每一行会以文件名作为前缀。如果把结果打印出来，大概会是这样的：

test1.log: foo

test1.log: bar

test1.log: baz

test2.log: Second log file

test2.log: Another line from the second log file

要理解SelectMany可能会费点脑子，我当时理解它就费了点力，不过理解它是很重要的。

在讲测试之前，还有几点关于SelectMany的行为细节需要说明：

l 参数校验是立即执行的，每个参数都不能是null

l 整个过程都是流式处理的。每次只会从输入序列中读取一个元素，然后生成一个子序列。然后每次只会返回子序列中的一个元素，返回子序列中的全部元素之后再去读取输入序列中的下一个元素，用它来生成下一个子序列，如此循环往复。

l 每个迭代器在使用完之后都会被关闭，正如你会预期的一样。

我们要测试什么呢？

我有一点变懒了，我不想再写参数为null的测试了。我给SelectMany的每一个重载都写了一个测试。我发现我无法把这些测试写得很清晰，不过还是拿出一个例子来，下面的代码是针对SelectMany的最复杂的重载的测试：

[Test]

public void FlattenWithProjectionAndIndex()

{

int[] numbers = { 3, 5, 20, 15 };

var query = numbers.SelectMany((x, index) => (x + index).ToString().ToCharArray(),

(x, c) => x + ": " + c);

// 3 => "3: 3"

// 5 => "5: 6"

// 20 => "20: 2", "20: 2"

// 15 => "15: 1", "15: 8"

query.AssertSequenceEqual("3: 3", "5: 6", "20: 2", "20: 2", "15: 1", "15: 8");

}

给这个测试做一点解释：

l 每一个数字都和它的序号相加 (3+0, 5+1, 20+2, 15+3)

l 相加的结果转成字符串，然后转成字符数组。（我们原本不需要调用ToCharArray的，因为String本身就实现了IEnumerable<char>，不过现在这样写比较清晰。）

l 然后把子序列中的每一个字符和原元素以“原元素：子序列字符”的形式组合在一起

注释部分是每一个输入元素对应的输出结果，测试最后一句代码给出了完整的输出序列。

是不是一团乱麻？希望你看了上面逐步分解的解释很清楚一点。好了，现在想办法让测试可以通过吧。

开始动手实现吧！

我们可以通过实现一个最复杂的重载并让其他的重载都调用它来实现SelectMany，或者也可以写一个没有参数校验的“Impl”方法，然后让四个重载都调用它。比如说，最简单重载可以这样实现：

public static IEnumerable<TResult> SelectMany<TSource, TResult>(

this IEnumerable<TSource> source,

Func<TSource, IEnumerable<TResult>> selector)

{

if (source == null)

{

throw new ArgumentNullException("source");

}

if (selector == null)

{

throw new ArgumentNullException("selector");

}

return SelectManyImpl(source,

(value, index) => selector(value),

(originalElement, subsequenceElement) => subsequenceElement);

}

不过我还是选择为每一重载写一个签名相同的“SelectManyImpl”方法。我觉得这样做可以让以后单步调试时更简单一些...而且这样让我们可以注意到不同重载之间的区别，代码是这样的：

// Simplest overload

private static IEnumerable<TResult> SelectManyImpl<TSource, TResult>(

IEnumerable<TSource> source,

Func<TSource, IEnumerable<TResult>> selector)

{

foreach (TSource item in source)

{

foreach (TResult result in selector(item))

{

yield return result;

}

// Most complicated overload:

// - Original projection takes index as well as value

// - There's a second projection for each original/subsequence element pair

private static IEnumerable<TResult> SelectManyImpl<TSource, TCollection, TResult>(

IEnumerable<TSource> source,

Func<TSource, int, IEnumerable<TCollection>> collectionSelector,

Func<TSource, TCollection, TResult> resultSelector)

{

int index = 0;

foreach (TSource item in source)

{

foreach (TCollection collectionItem in collectionSelector(item, index++))

{

yield return resultSelector(item, collectionItem);

}

这两个方法之间的相似性很是明显...不过我还是觉得保留着第一种形式很有用，如果我搞不清楚SelectMany的作用的话，通过第一种最简单的重载就可以很容易的弄懂。以此为基础再去理解余下的重载，跳跃性就不会那么大了。第一个重载在一定程度上起到了一个理解SelectMany的概念的垫脚石的作用。

有两点需要指出：

如果C#中可以使用“yield foreach selector(item)”这种表达式的话，上面的第一个方法就可以实现的稍简单一点。如果要在第二个方法中使用这种做法的话就会难一些，而且可能还要涉及到对Select的调用，这样的话就有点得不偿失了。

在第二个方法中，我没有显式的使用“checked”代码块，虽然说“index”是有可能溢出的。我没有看过BCL的实现是什么样的，但是我认为他们不会写“checked”的。考虑到前后一致性，我或许应该在每一个处理index的方法中都是用“checked”代码块，或者给整个程序集开启“checked”。

通过调用SelectMany来实现其他操作符

之前我提到过很多的LINQ操作符都可以通过调用SelectMany来实现。下面的代码就是这一观点的实例，我们通过调用SelectMany实现了Select，Where和Concat：

public static IEnumerable<TResult> Select<TSource, TResult>(

this IEnumerable<TSource> source,

Func<TSource, TResult> selector)

{

if (source == null)

{

throw new ArgumentNullException("source");

}

if (selector == null)

{

throw new ArgumentNullException("selector");

}

return source.SelectMany(x => Enumerable.Repeat(selector(x), 1));

}

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 source.SelectMany(x => Enumerable.Repeat(x, predicate(x) ? 1 : 0));

}

public static IEnumerable<TSource> Concat<TSource>(

this IEnumerable<TSource> first,

IEnumerable<TSource> second)

{

if (first == null)

{

throw new ArgumentNullException("first");

}

if (second == null)

{

throw new ArgumentNullException("second");

}

return new[] { first, second }.SelectMany(x => x);

}

Select和SelectMany使用Enumerable.Repeat来很方便的创建含有一个元素或不包含任何元素的序列。你也可以通过创建一个数组来代替使用Repeat的这种做法。Concat直接使用了一个数组：如果你理解了SelectMany的作用就是把多个序列组合为一个序列这一点的话，Concat这样实现看起来就很自然了。我估计Empty和Repeat可以通过递归来实现，尽管这样的话性能会很差。

现在，上面的代码是放在条件编译块里面的。如果大家希望我多写一些借助于SelectMany来实现的操作符的话，我可能会考虑把它单独分离一个项目出来。不过我感觉以上的代码已经足以显示SelectMany的灵活性了，再利用SelectMany来实现更多的其他操作符也未必能更加充分的说明这一点。

在理论的意义上，SelectMany也很重要，因为它为LINQ提供了monadic的特性。我不想在这一话题上说的更多，你可以读一读Wes Dyer的博客，或者直接搜索“bind monad SelectMany”就可以找到很多比我更聪明的人写的文章。

结论

SelectMany是LINQ中的基础之一，初看上去它很是令人生畏。但是一旦你理解了SelectMany的作用就是把多个序列组合起来这一点之后，它就很容易搞懂了。

下一次我们讨论All和Any，这两个操作符很适合放在一起来讲解。

本文链接

自己动手重新实现LINQ to Objects: 8 - Concat

2011-09-14T14:39:00Z

本文翻译自Jon Skeet的系列博文“Edulinq”。

本篇原文地址：

http://msmvps.com/blogs/jon_skeet/archive/2010/12/27/reimplementing-linq-to-objects-part-8-concat.aspx

上文讲的Count和LongCount返回的是数值类型，本文我们讲的Concat返回的是一个序列。

Concat是什么？

Concat只有一种签名形式，这让它使用起来很简单：

public static IEnumerable<TSource> Concat<TSource>(

this IEnumerable<TSource> first,

IEnumerable<TSource> second)

Concat的返回值依次包含了两个序列中的元素，也就是说把两个序列串联起来了。

我有时会觉得.NET没有提供Prepend/Append这样的方法是个遗憾，这两个方法应该可以和Concat做类似的事情，只不过它们把一个序列和一个单个的元素串联起来。如果要做一个填充着国家名和一个“None”值的下拉列表的话，这两个方法是很有用的。当然，向Concat中传入一个单元素的数组也可以达到同样的目的，但是我个人认为用特定的方法名做特定的事会让代码的可读性更高。MoreLINQ中的Concat方法可以做这件事，不过Edulinq的目的只是要实现LINQ to Objects中已有的方法。

和往常一样，我们列出Concat的行为：

l 参数校验需要立即执行：两个参数都不允许为null

l 返回值是延迟执行的：当Concat被调用时，两个参数不会立即被迭代

l 输入序列只有在需要的时候才会被迭代：如果你停止迭代输出序列时第一个输入序列还没有被耗尽的话，那么第二个序列根本就不会被迭代

这几点描述基本就涵盖了Concat的所有行为。

我们需要测试什么呢？

Concat的串联行为很容易被测试，只需要一个用例就够了。我们或许也可以测试输入空序列会如何，但是那种测试基本没有不通过的可能。

参数校验的测试方式和往常一样：调用方法时传入非法的参数，然后不去迭代方法的返回值。

最后，还有一个单元测试用来测试两个输入序列被迭代的时机。这个测试中用到了我们在测试Where时用过的ThrowingEnumerable：

[Test]

public void FirstSequenceIsntAccessedBeforeFirstUse()

{

IEnumerable<int> first = new ThrowingEnumerable();

IEnumerable<int> second = new int[] { 5 };

// No exception yet...

var query = first.Concat(second);

// Still no exception...

using (var iterator = query.GetEnumerator())

{

// Now it will go bang

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

}

[Test]

public void SecondSequenceIsntAccessedBeforeFirstUse()

{

IEnumerable<int> first = new int[] { 5 };

IEnumerable<int> second = new ThrowingEnumerable();

// No exception yet...

var query = first.Concat(second);

// Still no exception...

using (var iterator = query.GetEnumerator())

{

// First element is fine...

Assert.IsTrue(iterator.MoveNext());

Assert.AreEqual(5, iterator.Current);

// Now it will go bang, as we move into the second sequence

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

}

我们写测试来检查迭代器是否被Dispose掉了。但是我们可以预测到输入序列的迭代器应该会被合理的Dispose掉。实际上，第一个序列的迭代器会在第二个序列开始被迭代之前就被Dispose掉。

开始动手实现吧！

Concat的实现虽然比较简单，但是我写完之后还是觉得F#更值得拥有...实现分为参数校验和迭代器代码块两部分，每一部分都不复杂：

public static IEnumerable<TSource> Concat<TSource>(

this IEnumerable<TSource> first,

IEnumerable<TSource> second)

{

if (first == null)

{

throw new ArgumentNullException("first");

}

if (second == null)

{

throw new ArgumentNullException("second");

}

return ConcatImpl(first, second);

}

private static IEnumerable<TSource> ConcatImpl<TSource>(

IEnumerable<TSource> first,

IEnumerable<TSource> second)

{

foreach (TSource item in first)

{

yield return item;

}

foreach (TSource item in second)

{

yield return item;

}

如果不能利用迭代器代码块的话，这个实现会变得很麻烦。虽然不会特别难，但是我们需要记住当前正在迭代的是哪个序列。

如果是在用F#的话，我们可以使用yield!表达式来把它实现的更简单，yield!表达式作用于一整个序列而不是单个的元素。必需得承认在这种场景下使用yield!并不会带来什么性能上的提升（如果是在递归的场景下就很可能会有性能提升），但是能够用一个语句来yield返回整个序列确实是一种更优雅的风格。（Spec#中也有一个类似的结构叫做嵌套迭代器，用yield foreach来表示。）我对F#和Spec#了解的都不够深入，所以就不做更深入的比较了。不过我们在以后实现Edulinq的过程中还会遇到好几次“yield返回一个序列中的每个元素”的模式。请记住，我们不能把yield返回的代码抽取到一个单独的方法中去，因为“yield”表达式需要C#编译器的特殊处理。

结论

虽然我用的实现方式还是蛮简单的，但是我还是吐槽一下：）如果C#里面也有嵌套迭代器那多好啊，虽然说没有它也没有令我太苦恼。

Concat是一个很有用的操作符，不过它也不过是SelectMany的一个特例罢了。Concat只能把两个序列连接成一个序列，而SelectMany则可以把很多个序列连接成一个序列，而且SelectMany在有时还更有普遍性。下次我们会实现SelectMany，而且会展示一些基于SelectMany来实现其他操作符的例子。（等实现Aggregate的时候，我们会再次见到操作符只返回一个值的例子。）

附录：避免不必要的保持引用

有一条留言建议说要在遍历完第一个序列后把它设为null。这样，在遍历完第一个序列后，它就可以被垃圾回收了。如果采取这个建议，那么实现起来会是这样的：

private static IEnumerable<TSource> ConcatImpl<TSource>(

IEnumerable<TSource> first,

IEnumerable<TSource> second)

{

foreach (TSource item in first)

{

yield return item;

}

// Avoid hanging onto a reference we don't really need

first = null;

foreach (TSource item in second)

{

yield return item;

}

在普通情况下，把一个不再使用的局部变量设为null这种做法是没用的。因为当CLR在执行优化过的代码，并且没有挂上调试器时，垃圾收集器只关心在方法内部可能还会被访问的变量。

但是在我们这个特例中，这么做还是有用的。因为第一个参数并不是一个简单的局部变量，在C#编译器生成的隐藏类型中，它是一个实例字段，而CLR无法判断实例字段是否会被再次使用。

或许我们可以在调用GetEnumerator之前清空掉我们对“first”这个参数的唯一引用。我们可以写一个这样的方法：

public static T ReturnAndSetToNull<T>(ref T value) where T : class

{

T tmp = value;

value = null;

return tmp;

}

然后这样调用它：

foreach (TSource item in ReturnAndSetToNull(ref first))

我认为这样做绝对是有点过了，因为迭代器有可能还会持有对集合的引用。不过在遍历之后把“first”这个参数设为null在我看来是说得通的。

需要提醒你一下，我觉得.NET的LINQ to Objects的实现里面是不会这样做的。（以后我可能会用一个有finalizer的集合类来测试一下。）

本文链接

自己动手重新实现LINQ to Objects: 7 - Count和LongCount

2011-09-02T00:01:00Z

本文翻译自Jon Skeet的系列博文“Edulinq”。

本篇原文地址：

http://msmvps.com/blogs/jon_skeet/archive/2010/12/26/reimplementing-linq-to-objects-part-7-count-and-longcount.aspx

今天的文章要介绍两个LINQ操作符，因为它们实在是太类似了，所以放到一起来讲。Count和LongCount的实现非常相像，不同的只是方法名，返回值类型和几个变量。

Count和LongCount是什么呢？

Count和LongCount各自有两个重载：一个重载接受谓词，另一个不接受。下面是这四个方法的签名：

public static int Count<TSource>(

this IEnumerable<TSource> source)

public static int Count<TSource>(

this IEnumerable<TSource> source,

Func<TSource, bool> predicate)

public static long LongCount<TSource>(

this IEnumerable<TSource> source)

public static long LongCount<TSource>(

this IEnumerable<TSource> source,

Func<TSource, bool> predicate)

可以看到，Count和LongCount的方法签名的差别仅在于返回值类型，一个是int（Int32），一个是long（Int64）。

不接受谓词的重载返回输入序列中元素的个数；而接受谓词的重载则返回能够通过谓词验证的元素的个数。

这些方法有一些有趣的行为：

l 这四个方法都是扩展IEnumerable<T>的方法，你有可能会认为对于不接受谓词的那个重载来说，扩展IEnumerable会来得更好，因为没有什么会限制元素的类型。

l Count的不接受谓词的那个重载对于ICollection<T>和ICollection（.NET4中的接口）做了优化，因为这两个接口都定义有Count这个属性，这个属性的实现应该比遍历整个集合要快。LongCount则没有做优化，稍后的一节中我将会谈到这点。

l 接受谓词的重载中没有做任何优化，因为不迭代每一个元素就无法知道到底有多少个元素可以通过谓词的检验。

l 这四个方法都是立即执行的，都不涉及延迟执行。（仔细想想就明白了，这些方法仅仅返回一个int或long值，确实没什么可延迟执行的）。

l 所有的参数都只做非null的校验。

l 当输入集合的元素个数超出了int或long的上限值时，应该抛出OverflowException。

我们要测试什么呢？

我们需要对方法的优化做测试，这件事做起来比说起来难，因为我们需要测试以下四种情况：

l 输入序列同时实现了ICollection<T>和ICollection（这个简单，直接用List<T>）

l 输入序列实现了ICollection<T>但没有实现ICollection（还算简单，可以用HashSet<T>）

l 输入序列实现了ICollection但没有实现ICollection<T>，我还要要求这个类型实现了IEnumerable<T>（这样才能用到我们的扩展方法）。

l 输入序列既不实现ICollection也不实现ICollection<T>（简单，用我们已经实现了的Range来生成）

其中第三点比较麻烦。虽然有很多类型是实现了ICollection但没有实现ICollection<T>的（比如ArrayList），但是它们通常也不实现IEnumerable<T>，而我们的扩展方法是针对于IEnumerable<T>的。所以我只得自己写了一个叫做SemiGenericCollection的类。

上述的四种输入序列的类型都找到了，我们现在需要考虑到底怎么测试了。你可能会说我们可以通过检查输入序列是否被迭代过来测试方法是不是真的被优化了。但是要做这个测试就需要写一个有Count值但是其GetEnumerator方法会抛异常的集合类型。这个测试确实可行，但是我并没有做它。

对于接受谓词的重载来说，我们无需考虑那几个不同的集合接口，因为我们反正都不会优化这两个方法。

参数值为null的几个测试都比较简单，但是有另一个测试比较重要：溢出。我给Count创建了一个检验溢出行为的单元测试。很不幸，我们现在还不能在Edulinq的环境里运行它，因为我们还没有实现Concat。不过我还是把它写在这里：

[Test]

[Ignore("Takes an enormous amount of time!")]

public void Overflow()

{

var largeSequence = Enumerable.Range(0, int.MaxValue)

.Concat(Enumerable.Range(0, 1));

Assert.Throws<OverflowException>(() => largeSequence.Count());

}

如果Count的实现在应该抛出异常的时候把返回值溢出到了Int.MinValue的话，这个测试可以发现到它。

你可以看到，即使在实现了Concat并反注释了这段代码之后，这个测试也是被忽略掉了的，因为它需要遍历20亿个元素，对于几个简单快速的单元测试来说，这可不妙。其实20亿还不算太坏，因为LongCount的溢出测试需要遍历2的63次方个元素呢。要生成那么长的序列并不难，难的是遍历它，那要花很长的时间。对于接受谓词的重载来说，我们也需要做溢出测试，直到写这篇文章之前我都忘记了要写这个测试，而写测试的时候还发现了一个方法实现中的bug :)

来动手实现吧！

我们来看看接受谓词的那个重载的实现吧，它其实挺简单的：

public static int Count<TSource>(this IEnumerable<TSource> source,

Func<TSource, bool> predicate)

{

if (source == null)

{

throw new ArgumentNullException("source");

}

if (predicate == null)

{

throw new ArgumentNullException("predicate");

}

// No way of optimizing this

checked

{

int count = 0;

foreach (TSource item in source)

{

if (predicate(item))

{

count++;

}

return count;

}

请注意，在这里我们不需要返回一个序列，所以就没有用到迭代器代码块，因而也就无需把实现拆分到两个方法中去。

参数校验之后的方法主体部分相当简单，只有一点需要注意：整个的迭代过程都在“checked”代码块中。这样，如果count值溢出的话，就会抛出异常，而不会令count值成为负数。也有其他的方式可以实现这点：

l 可以只把给count加一的代码放在checked代码块中。

l 可以在每次给count加一之前检查count==int.MaxValue，如果确实相等，则抛出异常

l 可以给整个程序集都应用checked

我觉得把这段代码显式的放在checked代码块中是很有益的，因为这样可以很明显的凸显出对溢出的检查是方法正确性的需求这一事实。你可能更倾向于只把count++这一句代码放在checked代码块中，不过我个人觉得现在的做法更容易引起读代码的人对checked的注意，当然这只是我的主观偏好。还有，显式的checked代码块有可能会快一些，这一点我不确定，我还没有测试过。

除了与谓词有关的部分，上面的代码会全部出现在Count的优化过的实现中，我们就不再讲解了，直接写出代码：

public static int Count<TSource>(this IEnumerable<TSource> source)

{

if (source == null)

{

throw new ArgumentNullException("source");

}

// Optimization for ICollection<T>

ICollection<TSource> genericCollection = source as ICollection<TSource>;

if (genericCollection != null)

{

return genericCollection.Count;

}

// Optimization for ICollection

ICollection nonGenericCollection = source as ICollection;

if (nonGenericCollection != null)

{

return nonGenericCollection.Count;

}

// Do it the slow way - and make sure we overflow appropriately

checked

{

int count = 0;

using (var iterator = source.GetEnumerator())

{

while (iterator.MoveNext())

{

count++;

}

return count;

}

这个实现里面唯一的“新”代码就是关于优化的那段。优化代码中的两段基本是一样的，它们检查不同的集合接口类型，哪个检查通过就返回哪个的Count属性。我不知道.NET Framework的实现中是先检查ICollection还是先检查ICollection<T>，我可以写一个同时实现了这两个接口，但是在两个Count属性中返回不同的值的类型来测试一下，但是那么做有点太过了。对于良好实现的集合来说，这点性能差异算不了什么，我们先检查“最有可能”的接口，也就是泛型的ICollection<T>。

优化还是不优化？

LongCount的实现和Count的实现几乎完全一样，只是LongCount中使用long而不是int。

我对ICollection和ICollection<T>做了优化，但是我不认为.NET是如此实现的。（只要创建一个很大的byte数组，并比较一下Count和LongCount应用到这个数组上的耗时差距就可以了。）

关于Array.GetLongCount的使用存在一些争议，但是我觉得既然现在的CLR并不支持长度超过Int32.MaxValue的数组，那么这个问题现在就没什么好争议的，只有留待以后证明。除此之外，我不知道.NET的实现为什么没有优化。对一个实现了ICollection或ICollection<T>接口的类型来说，如果该集合中包含了超过Int32.MaxValue个元素的话，它的Count属性应该返回什么值呢？这一点并不明确。

欢迎提出各种建议。不过我还是要指出LongCount方法可能会更多的应用在Queryable中而不是Enumerable中，获取一个数据库表的长度的场景会比较多见，而获取一个内存中的集合的长度的场景则不那么常见。

结论

这是我们第一次接触返回数值而不是返回一个序列的LINQ操作符，很自然，这样的操作符更容易理解。这些方法很简单的执行，做一些优化，然后返回结果值。这些方法虽然简单，但是还是有一些东西很值得思考，比如说优化的问题，可惜优化的问题并没有一个确定的答案。

下一次我想我会去实现Concat，主要是因为实现了Concat就可以把对Count进行溢出测试的代码反注释了。Concat是一个会返回一个序列的操作符，不过它很简单。

本文链接

浅析延迟执行--实现，优点，陷阱以及题外话

2011-08-31T08:02:00Z

上周五在公司内部做了一个小型的sharing，讨论了一些与延迟执行有关的东西。现在把ppt和代码分享出来。如有谬误，请不吝指教 :)

代码在这儿： http://codeformyblog.codeplex.com/SourceControl/changeset/view/62764#1095173

ppt在这儿：

Deferred execution

View more presentations from cuipengfei

本文链接

自己动手重新实现LINQ to Objects: 6 - Repeat

2011-08-24T14:15:00Z

本文翻译自Jon Skeet的系列博文“Edulinq”。

本篇原文地址：

http://msmvps.com/blogs/jon_skeet/archive/2010/12/24/reimplementing-linq-to-objects-part-6-repeat.aspx

本文的主题是个无关紧要的方法，Repeat。关于Repeat，值得讨论的内容比Empty还要少。写这篇博文只是为了保证这个系列的完整性。

Repeat是什么？

Repeat是一个静态的泛型方法，不是扩展方法，它只有一个签名形式：

public static IEnumerable<TResult> Repeat<TResult>(

TResult element,

int count)

它返回一个序列，该序列中反复的包含“count”个指定的元素，。Repeat只需要一个参数校验：检验“count”不是负数。

我们要测试什么呢？

需要测试的东西真的不多。我只想到了四个场景：

l 一个简单的测试，把一个字符串重复三次

l 一个空序列（把一个元素重复0次）

l 一个多次包含null的序列（仅仅是为了证明“element”可以为null）

l 用负数作为“count”来证明参数校验会被执行，而且是立即执行的

以上这几点恐怕都不怎么令人兴起。

来动手实现吧！

在实现的时候我们唯一有可能做错的事就是把参数校验的代码和迭代器代码块写到一起。不过我们已经多次的做过“分割实现”了，所以我们肯定不会犯这个错误的。下面的代码就是乏善可陈的Repeat方法的全部了：

public static IEnumerable<TResult> Repeat<TResult>(TResult element, int count)

{

if (count < 0)

{

throw new ArgumentOutOfRangeException("count");

}

return RepeatImpl(element, count);

}

private static IEnumerable<TResult> RepeatImpl<TResult>(TResult element, int count)

{

for (int i = 0; i < count; i++)

{

yield return element;

}

这就是今天的全部内容了。其中值得指出的部分就是...没有什么值得指出的。

结论

其实没有什么结论可写。下一次我们讲Count和LongCount，那里面倒是有些有趣的东西可以细说。

本文链接

自己动手重新实现LINQ to Objects: 5 - Empty

2011-08-23T15:23:00Z

本文翻译自Jon Skeet的系列博文“Edulinq”。

本篇原文地址：

http://msmvps.com/blogs/jon_skeet/archive/2010/12/24/reimplementing-linq-to-objects-part-5-empty.aspx

这一篇继续讲非扩展方法。这次我们要讲的是Empty，它有可能是最简单的LINQ操作符了。

Empty是什么？

Empty是一个泛型的，静态的方法，它只有一个签名形式，不接受任何参数：

public static IEnumerable<TResult> Empty<TResult>()

它返回一个特定类型的空序列。这就是它的唯一作用。

它的行为只有一点比较有趣：文档上说Empty会对空序列做缓存。换句话说，对于同一个类型参数来讲，它每次都会返回同一个空序列。

我们要测试什么？

能够测试的东西也就只有两点：

l 返回序列为空。

l 对每个类型参数来说，返回值会被缓存起来。

和测试Range的时候的方法一样，我们用一个叫做EmptyClass的别名来引用包含Empty的类型。下面是测试代码：

[Test]

public void EmptyContainsNoElements()

{

using (var empty = EmptyClass.Empty<int>().GetEnumerator())

{

Assert.IsFalse(empty.MoveNext());

}

[Test]

public void EmptyIsASingletonPerElementType()

{

Assert.AreSame(EmptyClass.Empty<int>(), EmptyClass.Empty<int>());

Assert.AreSame(EmptyClass.Empty<long>(), EmptyClass.Empty<long>());

Assert.AreSame(EmptyClass.Empty<string>(), EmptyClass.Empty<string>());

Assert.AreSame(EmptyClass.Empty<object>(), EmptyClass.Empty<object>());

Assert.AreNotSame(EmptyClass.Empty<long>(), EmptyClass.Empty<int>());

Assert.AreNotSame(EmptyClass.Empty<string>(), EmptyClass.Empty<object>());

}

当然，以上代码并不能证明缓存不是每个线程一份。不过，这些测试也够了。

来动手实现吧！

现在看来，Empty的实现要比它的描述更有趣。如果不是要做缓存，我们可以这样实现Empty：

// Doesn't cache the empty sequence

public static IEnumerable<TResult> Empty<TResult>()

{

yield break;

}

不过我们需要遵守关于缓存的文档。要实现缓存其实也不难。有一个很方便的事实可以为我们所用，空数组是不可变的。数组的长度是固定的，通常无法使一个数组是只读的。数组中的任何一个元素都是可以改变的。不过一个空数组是不包含任何元素的，所以也就没有什么可被改变的。这样，我们就可以反复的重用同一个数组了。

现在你可能会猜我会用Dictionary<Type, Array>来实现，不过我们可以利用一个小手段。在一个泛型类型中，可以用一个静态变量来实现针对类型参数的缓存，因为每一个传入了类型参数的泛型类型的静态变量都是不同的。

很不幸，Empty是一个非泛型类型中的方法。所以我们需要创建另一个泛型类型来包含缓存。这很容易做到，而且CLR还帮我们做到了线程安全的类型初始化。所以，我们最后的实现会是这样的：

public static IEnumerable<TResult> Empty<TResult>()

{

return EmptyHolder<TResult>.Array;

}

private static class EmptyHolder<T>

{

internal static readonly T[] Array = new T[0];

}

以上的实现遵守了所有的关于缓存的文档，而且代码行数也很少。不过这个实现方式需要你很好的了解.NET中泛型的工作方式。这种做法和我们上一篇采取的策略相反，我们选择了一种比较难懂的方式，而没有选择使用字典的易懂的方式。不过我很满意这种方案，因为一旦你了解了泛型类型和静态变量的工作方式，这段代码就很简单了。

结论

Empty的实现就是这样的。下一个操作符Repeat有可能会更简单，虽然它也要分成两个方法来实现。

附录

因为以上讲解的方法有点难懂，所以下面再提供另一种实现：

public static IEnumerable<TResult> Empty<TResult>()

{

return EmptyEnumerable<TResult>.Instance;

}

#if AVOID_RETURNING_ARRAYS

private class EmptyEnumerable<T> : IEnumerable<T>, IEnumerator<T>

{

internal static IEnumerable<T> Instance = new EmptyEnumerable<T>();

// Prevent construction elsewhere

private EmptyEnumerable()

{

}

public IEnumerator<T> GetEnumerator()

{

return this;

}

IEnumerator IEnumerable.GetEnumerator()

{

return this;

}

public T Current

{

get { throw new InvalidOperationException(); }

}

object IEnumerator.Current

{

get { throw new InvalidOperationException(); }

}

public void Dispose()

{

// No-op

}

public bool MoveNext()

{

return false; // There's never a next entry

}

public void Reset()

{

// No-op

}

#else

private static class EmptyEnumerable<T>

{

internal static readonly T[] Instance = new T[0];

}

#endif

这下大家都满足了吧：）

本文链接

自己动手重新实现LINQ to Objects: 4 - Range

2011-08-22T14:07:00Z

本文翻译自Jon Skeet的系列博文“Edulinq”。

本篇原文地址：

http://msmvps.com/blogs/jon_skeet/archive/2010/12/24/reimplementing-linq-to-objects-part-4-range.aspx

本篇博文较短，接下来的几篇估计也会比较短。我觉得只有很相似的几个LINQ操作符才适合放到同一篇博文里面，比如Count和LongCount就比较适合放在一起讲。不过我也要采纳读者的意见，如果你喜欢“肥胖”一点的博文的话，请留言说明。

本文将要讲解Range操作符。

Range操作符是什么？

Range只有一种方法签名：

public static IEnumerable<int> Range(

int start,

int count)

和LINQ中的其他操作符不同，Range不是扩展方法，它就是一个普通的静态方法。Range返回一个可枚举的对象，该对象会yield返回“count”个整数，返回的整数序列从“start”开始，逐次加一。举例来说，Enumerable.Range(6,3)会返回6，7，8。

由于Range不会接受输入序列，所以也就无所谓对输入的流式处理和缓冲了。不过它有以下几点行为：

l 参数的校验需要立即执行；参数count不可以为负数，也不可以让输出值中包含超出Int32范围的值。

l 输出值是被延迟输出的。Range的执行效率应该比创建并返回一个“count”长度的数组来得更高。

我们要如何测试呢？

要测试普通的静态方法就给我们带来了一个新的挑战，因为我们要在原版的LINQ实现和Edulinq的实现之间做切换。这是由我所使用的命名空间所带来的缺陷，单元测试写在Edulinq.Tests这个命名空间内，我们的实现写在Edulinq这个命名空间中。在编译器寻找一个类型的时候，父级命名空间会比其他的通过using引入的命名空间拥有更高的优先级，即使是使用using来显式引入一个类型的别名时也是如此。

我选择的解决方式是用一个using指令来引入一个叫做RangeClass的别名。using指令要么指向System.Linq.Enumerable要么指向Edulinq.Enumerable。测试代码中用到Range时都是这样写：RangeClass.Range。为此我创建了两个项目配置，其中一个定义了叫做NORMAL_LINQ的预处理符号，另一个则没有定义任何预处理符号，这样就可以在两种LINQ实现之间做切换了。RangeTest.cs中会包含如下的代码：

#if NORMAL_LINQ

using RangeClass = System.Linq.Enumerable;

#else

using RangeClass = Edulinq.Enumerable;

#endif

当然了，也有别的办法可以替代以上的方式：

l 可以把单元测试代码换到另外一个命名空间中去。

l 也可以让项目的引用项依赖于不同的项目配置，用于测试原版LINQ的项目配置不包含对Edulinq的引用，而用于测试Edulinq的项目配置则不引用System.Core。这样就可以在NORMAL_LINQ的预处理符号下直接使用using System.Linq，并直接使用Enumerable.Range。测试默认的LINQ实现时亦是如此。

我喜欢上面提到的第二种方式，但是那需要手动修改测试工程的工程文件，因为Visual Studio没有提供任何根据不同条件引用不同引用项的功能。我以后或许会用到这个方法，欢迎提供建议。

我们要测试什么呢？

Range需要的测试并不多，我只有八个方面需要测试，而且都不怎么很特别：

l 一个简单有效的Range操作应该可以通过AssertSequenceEqual的测试。

l 起始值应该可以是负数。

l Range(Int32.MinValue, 0)会返回一个空序列。

l Range(Int32.MaxValue, 1)会返回仅包含Int32.MaxValue的序列。

l count不可以为负数。

l count可以为0。

l start+count-1不可以超过Int32.MaxValue（所以Range(Int32.MaxValue, 2)应该是一个无效操作）。

l start+count-1可以等于Int32.MaxValue（所以Range(Int32.MaxValue, 1)应该是一个有效操作）。

最后两项要分别被几组不同的数据测试，这几组数据是：大的start值和小的count值，小的start值和大的count值，还有一组是start和count都相当大。

请注意我没有做针对于惰性求值的测试，我确实可以测一下返回值是否实现了任何其他的集合接口，不过那会显得有点奇怪。不过我们有一些测试中用到的count值非常大，给这么大的集合分配内存几乎肯定要失败。

开始实现吧！

你肯定早就猜到了，我们将会用分隔开的两个方法来实现Range。一个public的方法用来立即执行参数校验，还有一个private的方法用来做核心部分的工作，其中包含迭代器代码块。

由于一开始就确定了参数不会超过Int32的上下限，我们在实现的主体部分就可以随意一点了。

public static IEnumerable<int> Range(int start, int count)

{

if (count < 0)

{

throw new ArgumentOutOfRangeException("count");

}

// Convert everything to long to avoid overflows. There are other ways of checking

// for overflow, but this way make the code correct in the most obvious way.

if ((long)start + (long)count - 1L > int.MaxValue)

{

throw new ArgumentOutOfRangeException("count");

}

return RangeImpl(start, count);

}

private static IEnumerable<int> RangeImpl(int start, int count)

{

for (int i = 0; i < count; i++)

{

yield return start + i;

}

有几点需要说明：

l 第二段参数校验的代码检查的是“start”和“count”这二者的合法性，而不是仅仅检查“count”。如果能给ArgumentOutOfRangeException（或者是ArgumentException）传入多个参数名就好了，这样就能在异常信息中指出多个参数不合法。话虽这么说，.NET Framework的实现也是只会指出“count”不合法。

l 第二段参数校验的代码还可以有很多其他的写法，把所有的操作数都转换成long并不是我们仅有的选择。不过我觉得我选择的这个方法是最简单的，而且也是正确的。采取这种方式，我无须考虑多种情况并保证每一种都是正确的。使用Int64可以确保不会有溢出，也无需去考虑checked或unchecked。

l Private方法中的循环也有其他的实现方式，不过我认为我用的这个是最简单的。一种很容易想到的替代方案就是用两个变量，一个是已经返回过的值的个数，另一个是下一个要返回的值，每次循环都把这两个值各自加一。还有一种比较复杂的替代方案是只使用一个循环变量，但是那样的话你就不能写“value < start + count”了，因为最后一个返回值有可能是Int32.MaxValue，你也不能写“value <= start + count - 1”了，因为传入的参数有可能是Int32.MaxValue和0。我不想在代码中处理这么多种临界情况，所以我选择了一个简单正确的方式。如果你真的非常非常注重Range的效率的话，你应该去调查一下其他的可行方案。

写本文之前，我没有给Range(Int32.MaxValue, 1) 和Range(Int32.MinValue, 0)写出好的单元测试。不过写了上面的那段关于替代性方案的话之后，我找到了合适的测试用例。寻找替代方案可以帮助我想到更多的测试用例，这事儿多有趣。

结论

实现Range有助于测试其他的操作符，比如说Count。现在既然我已经实现了一个非扩展方法的LINQ操作符了，那无妨把另外两个（Empty和Repeat）也实现了。其实我已经实现了“Empty”了，希望今天就能把它整理成文。Repeat也不需要多久就能完工，然后我们就可以开始着手于Count和LongCount了。

本文中的代码很好的诠释了这种情况：有时，写“傻”一点的代码会比写短一点，快一点的代码更好，因为它更易于读懂。无疑，以后博文中我还会写更多的“傻”代码的。

本文链接

自己动手重新实现LINQ to Objects: 3 - Select

2011-08-21T15:22:00Z

本文翻译自Jon Skeet的系列博文“Edulinq”。

本篇原文地址：

http://msmvps.com/blogs/jon_skeet/archive/2010/12/23/reimplementing-linq-to-objects-part-3-quot-select-quot-and-a-rename.aspx

距离上次写完本系列博文的第一篇和第二篇已经有一段日子了，希望接下来的进度会快一些。

现在我给本项目在Google Code上建立了源码管理，现在就无需每篇博文包含一个zip文件了。创建项目时，我给它取了个显而易见的名字，叫做Edulinq。我修改了代码中的命名空间，而且现在这一系列博文的tag也修改为了Edulinq了。好了，闲话少叙...我们来开始重新实现LINQ吧，这次要实现Select操作符。

Select操作符是什么？

和Where类似，Select也有两个重载：

public static IEnumerable<TResult> Select<TSource, TResult>(

this IEnumerable<TSource> source,

Func<TSource, TResult> selector)

public static IEnumerable<TResult> Select<TSource, TResult>(

this IEnumerable<TSource> source,

Func<TSource, int, TResult> selector)

其第二个重载让投影操作可以访问到序列元素的index。

先说简单的东西：Select方法把一个序列投影成为另一个序列：“selector”这个作为参数的委托会被依次应用到输入序列中的每一个元素上，并每次yield返回一个输出元素。Select的行为和Where很类似（实在是太类似了，以至于下面一段文字都是从上一篇文章中复制过来的，只是稍加修改）：

l Select不会对输入序列做任何修改。

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

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

l 它以流式处理结果：它每次只处理一个结果元素。

l 你每在输出序列上迭代一次，Select方法就会在输入序列上迭代一次，这二者是严格对应的。

l 每次yield返回结果值的时候，“selector”这个委托就会被调用一次。

l 如果输出序列的迭代器被Dispose掉的话，对应的输入序列的迭代器也会被Dispose掉。

我们要测试什么？

对Select的测试和对Where的测试也是很类似的，之前我们是针对Where的过滤功能来做测试，现在我们是针对Select的投影功能来做测试。

有几个测试比较有趣。首先，你会发现Select方法是泛型的，而且有两个泛型参数，分别是TSource和TResult。虽然这两个参数的含义不言自明，不过还是得写一个单元测试来测一下TSource和TResult分别为不同类型的情况，比如说把int转换成string的情况。

[Test]

public void SimpleProjectionToDifferentType()

{

int[] source = { 1, 5, 2 };

var result = source.Select(x => x.ToString());

result.AssertSequenceEqual("1", "5", "2");

}

然后我们看另一个测试，这个测试给我们展示了使用LINQ有可能会遇到的奇怪的副作用。其实我们本可以在Where的单元测试中做这个例子的，不过针对Select做起来更清晰一些：

[Test]

public void SideEffectsInProjection()

{

int[] source = new int[3]; // Actual values won't be relevant

int count = 0;

var query = source.Select(x => count++);

query.AssertSequenceEqual(0, 1, 2);

query.AssertSequenceEqual(3, 4, 5);

count = 10;

query.AssertSequenceEqual(10, 11, 12);

}

请注意我们只调用了Select一次，但是对Select方法返回值的多次迭代结果都不同，这是因为“count”这个变量的值被保留住了并在每一次的投影过程中都会被修改。希望您不要写出这种代码。

再然后，我们可以写一些同时包含“select”和“where”的查询表达式：

[Test]

public void WhereAndSelect()

{

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

var result = from x in source

where x < 4

select x * 2;

result.AssertSequenceEqual(2, 6, 4, 2);

}

如果你用过LINQ to Objects的话，那么上面这些东西对你来说应该是很熟悉很亲切的，没有什么令人惊讶的。

来动手实现吧！

我们实现Select的方式和实现Where的方式差不多。我只是把Where的实现的代码复制过来，稍加修改，这二者真的就是如此的相似。详细说来就是：

l 我们利用迭代器代码块来轻松实现序列的返回。

l 要用到迭代器代码块就意味着必须要把参数校验的代码和核心实现代码分离开。（我写完上一篇博文之后了解到VB11中将会有匿名迭代器，匿名迭代器可以解决这个问题。哎。羡慕VB用户的感觉怪怪的，但是我会学着接受现实的。）

l 我们在迭代器代码块中使用foreach，这样就可以保证在输出序列的迭代器被Dispose时或者输入序列的元素被迭代完时，输入序列的迭代器可以被妥当的Dispose掉。

由于Select的实现和Where的实现实在是太类似了，下面我直接给出代码。Select方法的重载（含有index的那一个）的实现代码就不展示了，因为它和下面的代码差别实在太小了。

public static IEnumerable<TResult> Select<TSource, TResult>(

this IEnumerable<TSource> source,

Func<TSource, TResult> selector)

{

if (source == null)

{

throw new ArgumentNullException("source");

}

if (selector == null)

{

throw new ArgumentNullException("selector");

}

return SelectImpl(source, selector);

}

private static IEnumerable<TResult> SelectImpl<TSource, TResult>(

this IEnumerable<TSource> source,

Func<TSource, TResult> selector)

{

foreach (TSource item in source)

{

yield return selector(item);

}

很简单，对吧？真正用来实现功能的代码还没有参数校验的代码长呢。

结论

虽然说我不想让我的读者感到无聊（你们中的有些人可能会感到惊讶），但是我还是得承认本篇文章颇有些无趣。我重复的强调“和Where很类似”，强调了那么多次，搞得都有点乏味了，不过这样才足以说明实现Select并没有你可能想象的那么复杂。

下次（我希望就在几天之内）我会写点不一样的东西。我还不确定下次要写哪个方法，待选的方法还有很多...

本文链接