我应该如何实现IEqualityComparer <T> 。等于

Question

关于IEqualityComparer，是否有理由为什么Equals(T x, T y)实现应该是我下面所没有的？

public class MyEquality : IEqualityComparer<MyType>
{
    //My Equals(T x, T y) always looks like this
    public bool Equals(MyType x, MyType y)
    {
        return this.GetHashCode(x).Equals(this.GetHashCode(y));
    }

    public int GetHashCode(MyType obj)
    {
        //assume MyType has a non-nullable member called ID
        return obj.ID.GetHashCode();
    }
}

Answer 1

是。 哈希码可能会冲突，实际上，它们会具有多种类型。 它们仅存在以确保哈希表中的值相等分布，它们对确定值的相等性没有用。 埃里克利珀也有这样的取值（和另外一个 ）：

使用32位哈希码作为“唯一”标识符是一个非常糟糕的主意。 哈希值本身并不是随机的，但是如果它们分布合理，那么它们也很可能是我们的目的。 您可能会想：“当然，显然它们并不是真正唯一的，因为可能的值超过40亿，但只有40亿的哈希码可用。 但是散列值太多了，赔率非常好，我将为我的散列获得唯一的值。” 但是机会真的那么好吗？ 9300个对象并不多，只有1％的对象发生碰撞的可能性很高。

话虽如此，如果您的ID是确定相等性时唯一要注意的事情，那么比较该ID就足够了。 但不是其哈希码，因为哈希码仅表示

a .GetHashCode（）≠ b .GetHashCode（）→ a ≠ b

注意，对于哈希码相同的情况，没有任何说明。

Answer 2

是的，有：如果ID的哈希码现在或将来某个时间不适合int ，当具有相同哈希码的不相等对象开始评估为相等时，您将感到非常讨厌。 如果以后有人决定ID应该是long或Guid ，则MyEquality将继续愉快地进行编译，但是其行为将是无法避免的错误。

无关紧要的是，如果MyType是一个类，则可能需要采取一些措施来防止x或y为null时崩溃：尽管IEqualityComparer<T>的协定没有明确要求它（与object.Equals一样）在IEqualityComparer<T>.Equals处理null是一个好主意。在您搜索可能包含null对象的容器时，该情况均IEqualityComparer<T>.Equals 。

Answer 3

当然。 在一个对象中，您只关心一个或多个属性是相同的，就可以认为它们对于您的目的是相等的。

Answer 4

如果要比较列表list1和List list2，如果它们具有一些“公共”元素，例如list1 = {“ apparent”，“ obvious”}和list2 = {“ aPPARENT”，“ oBVIOUS”}

如果您对权益的定义如下：

• 第一个字符必须相等，区分大小写
• 其余字符不能相等（区分大小写）

您必须在IEqualityComparer中定义自己的逻辑。

此外，在LINQ中，所有Where，Any，Except，Intersect等子句都可能需要附加的IEqualityComparer对象，以挂钩自定义逻辑。