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

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

本篇原文地址:

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

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

本文将要讲解Range操作符。
 

Range操作符是什么?
 

Range只有一种方法签名:

public static IEnumerable<int> Range( 

    int start, 

    int count)

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

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

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

输出值是被延迟输出的。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
 

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

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

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

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

我们要测试什么呢?
 

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

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

起始值应该可以是负数。

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

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

count不可以为负数。

count可以为0

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

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

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

请注意我没有做针对于惰性求值的测试,我确实可以测一下返回值是否实现了任何其他的集合接口,不过那会显得有点奇怪。不过我们有一些测试中用到的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; 

    } 

}
 

有几点需要说明:
 

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

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

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

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

结论
 

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

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

posted on 2011-08-22 22:07  崔鹏飞  阅读(1611)  评论(2编辑  收藏  举报

导航