败给了IEqualityComparer

LINQ中的Distinct方法能够帮助我们轻松地剔除集合里面相同的元素。 它提供了2个重载函数,其中一个允许我们传入IEqualityComparer<T> 接口, 给我们充分的自由来决定2个元素是否相同。

为了实现剔除一堆string集合中相同的string,我写下了如下的代码。 注:不区分大小写

source.Distinct(new StringComparer());

 

internal class StringComparer : IEqualityComparer<string>
{
    public bool Equals(string x, string y)
    {
        return string.Compare(x, y, true) == 0;
    }

    public int GetHashCode(string obj)
    {
        return obj.GetHashCode();
    }
}

 

结果调试的时候始终不对,结果始终不能剔除那些只是大小写有区别的字符串,如"good” 跟"Good”.

当时因为时间紧张,就先提交了,事后发现原来还是自己不严谨,败给了GetHashCode()方法。

印象中自己没怎么实现过IEqualityComparer, 到实现过多次的IComparer接口。在上面的例子中虽然我意识到在比较的时候忽略大小写,但是再实现GetHashCode(), 随手地用了上面的方式。

问题就在这,既然我们认为"good” 跟"Good”是一样的,那么我们必须给他俩返回一样的hash code,但显然以我上面实现方式它俩返回的hash code是不一样的。

在鄙人的《避免陷阱,重现Equals方法您需要注意的其中2个原则》与《Just Reflect 》 中,其实我是多次提到了这个问题,想不到这次还是马失前蹄了,罪过啊。

所以正确的写法应该是:

public int GetHashCode(string obj)
    {
        return obj.ToUpper().GetHashCode();
    }


扩充话题: 既然第一次写法返回的结果不正确,这就能说明Distinct扩展方法是先调用GetHashCode(), 再调用Equals(). 因为如果是先调用Equals()方面,理论上"good” 跟"Good” 是能剔除一个的。 问题是为什么要先调用GetHashCode(), 或则换种说法是为什么Distinct方法接受IEqualityComparer接口, 而不是IComparer接口。 因为判定2个对象是否相同,只需调用Equals() 方法就好。或者说因为 ICompare接口返回的是int,而不是直接的bool类型吗?那为啥不是IEquatable呢?

 

调试Framework的源代码,可以发现如下踪迹:

static IEnumerable<TSource> DistinctIterator<TSource>(IEnumerable<TSource> source, IEqualityComparer<TSource> comparer) {
    Set<TSource> set = new Set<TSource>(comparer);
    foreach (TSource element in source)
        if (set.Add(element)) yield return element;
}

也就是说Distinct执行时在遍历集合的时候,是把那些非重复的元素放在了Set容器里,而非普通的List,这样的好处是因为Set是一个HashTable结构的容器类,可以提高执行效率。我们知道在HashTable里找一个元素的间复杂度为O(1). 而在List里查找的效率却是O(n)。

因此将Distinct方法接受IEqualityComparer接口,是很有必要的, 目前按照它的实现方式时间复杂度为O(n)。 而如果改为传IEquatable接口,那么时间复杂度就得变为O(n2).

posted @ 2010-11-22 09:36  Anders06  阅读(2002)  评论(7编辑  收藏