我想了解应该使用IEqualityComparer<T> 和IEquatable<T> 的场景。
两者的 MSDN 文档看起来非常相似。
【问题讨论】：
EqualityComparer<T> 而不是实现接口“因为EqualityComparer<T> 使用IEquatable<T> 测试相等性
IEquatable<T> 的T 创建一个自定义集合。否则，像List<T> 这样的集合会不会有某种微妙的错误？
标签： c# .net equals iequalitycomparer iequatable
IEqualityComparer<T> 是一个对象接口，用于对T 类型的两个对象进行比较。
IEquatable<T> 用于T 类型的对象，以便它可以将自己与另一个相同类型的对象进行比较。
【讨论】：
IEqualityComparer<T> 是对象的接口（通常是不同于T 的轻量级类），它提供了对T 进行操作的比较函数
在决定是使用IEquatable<T>还是IEqualityComparer<T>时，
有人可能会问：
是否有测试
T的两个实例是否相等的首选方法，或者有几种同样有效的方法？
T 本身，因此T 的一个实例具有如何将自己与T 的另一个实例进行比较的内部知识。
1234563但通过其他“外部”类。因此，在测试T 的两个实例是否相等时，由于T 对相等没有内部理解，因此您必须根据您的具体要求明确选择执行测试的IEqualityComparer<T> 实例。
示例：
让我们考虑这两种类型（应该有value semantics）：
interface IIntPoint : IEquatable<IIntPoint>
{
int X { get; }
int Y { get; }
}
interface IDoublePoint // does not inherit IEquatable<IDoublePoint>; see below.
{
double X { get; }
double Y { get; }
}
为什么这些类型中只有一种会继承IEquatable<>，而不是另一种？
理论上，比较任一类型的两个实例只有一种明智的方法：如果两个实例中的X 和Y 属性相等，则它们相等。根据这种想法，这两种类型都应该实现IEquatable<>，因为似乎不太可能有其他有意义的方法来进行相等性测试。
这里的问题是comparing floating-point numbers for equality might not work as expected, due to minute rounding errors。比较近似相等的浮点数有不同的方法，每种方法都有特定的优点和权衡，您可能希望能够自己选择哪种方法合适。
sealed class DoublePointNearEqualityComparerByTolerance : IEqualityComparer<IDoublePoint>
{
public DoublePointNearEqualityComparerByTolerance(double tolerance) { … }
…
public bool Equals(IDoublePoint a, IDoublePoint b)
{
return Math.Abs(a.X - b.X) <= tolerance && Math.Abs(a.Y - b.Y) <= tolerance;
}
…
}
请注意，我链接到的页面（上面）明确指出，这个近似相等测试有一些弱点。由于这是一个 IEqualityComparer<T> 实现，如果它对您的目的不够好，您可以简单地换掉它。
【讨论】：
IEqualityComparer<T>实现必须实现等价关系，这意味着在all 在两个对象比较等于第三个的情况下，它们必须彼此比较相等。任何以与上述相反的方式实现IEquatable<T> 或IEqualityComparer<T> 的类都会被破坏。
IEqualityComparer<String> 认为 "hello" 等于 "Hello" 和 "hElLo" 必须认为 "Hello" 和 "hElLo" 彼此相等，但对于大多数比较方法来说这不会有问题。跨度>
GetHashCode 应该可以让您快速确定两个值是否不同。规则大致如下： (1) GetHashCode 必须始终为相同的值生成相同的哈希码。 (2) GetHashCode 应该快（比Equals 快）。 (3) GetHashCode 不必精确（不如Equals 精确）。这意味着它可能为不同的值生成相同的哈希码。您可以做得越精确越好，但保持快速可能更重要。
您已经了解了它们是什么的基本定义。简而言之，如果您在类T 上实现IEquatable<T>，则Equals 类型对象上的Equals 方法会告诉您对象本身（正在测试相等性的对象）是否等于相同的另一个实例输入T。而IEqualityComparer<T> 用于测试T 的任何两个实例的相等性，通常在T 的实例范围之外。
至于它们的用途，起初可能会令人困惑。从定义中应该很清楚，因此IEquatable<T>（在类T 本身中定义）应该是表示其对象/实例的唯一性的事实标准。 HashSet<T>、Dictionary<T, U>（考虑到GetHashCode 也被覆盖）、Contains 上的List<T> 等都利用了这个。在T 上实现IEqualityComparer<T> 对上述一般情况没有帮助。随后，在T 以外的任何其他类上实现IEquatable<T> 几乎没有价值。这个：
class MyClass : IEquatable<T>
很少有意义。
另一方面
class T : IEquatable<T>
{
//override ==, !=, GetHashCode and non generic Equals as well
public bool Equals(T other)
{
//....
}
}
是应该怎么做的。
IEqualityComparer<T> 在您需要自定义相等性验证时很有用，但不是一般规则。例如，在 Person 的某个类中，您可能需要根据两个人的年龄来测试他们是否相等。在这种情况下，您可以这样做：
class Person
{
public int Age;
}
class AgeEqualityTester : IEqualityComparer<Person>
{
public bool Equals(Person x, Person y)
{
return x.Age == y.Age;
}
public int GetHashCode(Person obj)
{
return obj.Age.GetHashCode;
}
}
要测试它们，请尝试
var people = new Person[] { new Person { age = 23 } };
Person p = new Person() { age = 23 };
print people.Contains(p); //false;
print people.Contains(p, new AgeEqualityTester()); //true
T 上的 IEqualityComparer<T> 同样没有意义。
class Person : IEqualityComparer<Person>
的确，这可行，但看起来不太好，并且不符合逻辑。
通常你需要的是IEquatable<T>。理想情况下，您只能拥有一个IEquatable<T>，而多个IEqualityComparer<T> 可以根据不同的标准。
IEqualityComparer<T> 和IEquatable<T> 与Comparer<T> 和IComparable<T> 完全相同，它们用于比较而不是等同；一个很好的线程here 我写了相同的答案:)
【讨论】：
public int GetHashCode(Person obj) 应该返回 obj.GetHashCode()
obj.Age.GetHashCode。将编辑。
person.GetHashCode.... 为什么你会覆盖它吗？ - 我们覆盖它是因为IEqualityComparer 的全部意义在于根据我们的规则（我们真正熟悉的规则）进行不同的比较实现。
Age 属性进行比较，因此我调用Age.GetHashCode。年龄的类型是int，但无论是什么类型的.NET 中的哈希码合约都是different objects can have equal hash but equal objects cant ever have different hashes。这是我们可以盲目相信的合同。当然，我们的自定义比较器也应遵守此规则。如果调用someObject.GetHashCode 会破坏事情，那么这是someObject 类型的实现者的问题，这不是我们的问题。
IEqualityComparer 用于在外部实现两个对象的相等性时使用，例如如果您想为没有源代码的两种类型定义比较器，或者为两种事物之间的相等性仅在某些有限的上下文中才有意义的情况。
IEquatable 用于实现对象本身（被比较是否相等的对象）。
【讨论】：
一个比较两个Ts。另一个可以将自己与其他Ts 进行比较。通常，您一次只需要使用一个，而不是两个。
【讨论】：