.NET 类何时应该重写 Equals()？什么时候不应该？

Question

VS2005 文档Guidelines for Overloading Equals() and Operator == (C# Programming Guide) 部分声明

不建议在非不可变类型中覆盖运算符 ==。

较新的 .NET Framework 4 文档 Guidelines for Implementing Equals and the Equality Operator (==) 省略了该声明，尽管社区内容中的一篇文章重复了该声明并引用了旧文档。

似乎至少对于一些琐碎的可变类来说重写 Equals() 是合理的，例如

public class ImaginaryNumber
{
    public double RealPart { get; set; }
    public double ImaginaryPart { get; set; }
}

在数学中，具有相同实部和相同虚部的两个虚数实际上在测试相等性的时间点相等。断言它们不相等是不正确的，如果具有相同 RealPart 和 ImaginaryPart 的单独对象未被 Equals() 覆盖，则会发生这种情况。

另一方面，如果覆盖 Equals()，则还应该覆盖 GetHashCode()。如果将覆盖 Equals() 和 GetHashCode() 的 ImaginaryNumber 放置在 HashSet 中，并且可变实例更改了它的值，则该对象将不再在 HashSet 中找到。

MSDN 是否不正确地删除了关于不为非不可变类型覆盖 Equals() 和 operator== 的指南？

对于“在现实世界中”所有属性的等价性意味着对象本身是相等的（如ImaginaryNumber）的可变类型重写 Equals() 是否合理？

如果合理，当对象实例参与 HashSet 或其他依赖于 GetHashCode() 不变的东西时，如何最好地处理潜在的可变性？

更新

刚刚遇到这个in MSDN

通常，当类型的对象是 期望被添加到某种集合中，或者当他们的 主要目的是存储一组字段或属性。你可以 将您对价值平等的定义建立在对所有 类型中的字段和属性，或者您可以将定义基于 子集。但在任何一种情况下，在类和结构中，你的 实施应遵循等效的五项保证：

Answer 1

我开始意识到我希望 Equals 有两种不同的含义，具体取决于上下文。在权衡了这里的输入以及here 之后，我针对我的特殊情况确定了以下内容：

我没有覆盖Equals() 和GetHashCode()，而是保留了Equals() 表示类的身份相等，而Equals() 表示结构的值相等这一共同但绝不是普遍存在的约定。这个决定的最大驱动力是散列集合中对象的行为（Dictionary<T,U>，HashSet<T>，...），如果我偏离了这个约定。

那个决定让我仍然缺少价值平等的概念（如discussed on MSDN）

当你定义一个类或结构时，你决定它是否有意义 为值相等（或等价）创建自定义定义 方式。通常，当 类型应该被添加到某种集合中，或者当 它们的主要目的是存储一组字段或属性。

希望值相等（或者我称之为“等价”）概念的典型案例是在单元测试中。

给定

public class A
{
    int P1 { get; set; }
    int P2 { get; set; }
}

[TestMethod()]
public void ATest()
{
    A expected = new A() {42, 99};
    A actual = SomeMethodThatReturnsAnA();
    Assert.AreEqual(expected, actual);
}

测试将失败，因为Equals() 正在测试引用相等性。

当然可以修改单元测试以单独测试每个属性，但这会将等价概念从类中移到类的测试代码中。

为了将知识封装在类中，并为测试等效性提供一致的框架，我定义了一个我的对象实现的接口

public interface IEquivalence<T>
{
    bool IsEquivalentTo(T other);
}

实现通常遵循这种模式：

public bool IsEquivalentTo(A other)
{
    if (object.ReferenceEquals(this, other)) return true;

    if (other == null) return false;

    bool baseEquivalent = base.IsEquivalentTo((SBase)other);

    return (baseEquivalent && this.P1 == other.P1 && this.P2 == other.P2);
}

当然，如果我有足够多的类和足够的属性，我可以编写一个帮助器，通过反射构建表达式树来实现IsEquivalentTo()。

最后，我实现了一个扩展方法，测试两个IEnumerable<T>的等价性：

static public bool IsEquivalentTo<T>
    (this IEnumerable<T> first, IEnumerable<T> second)

如果T 实现IEquivalence<T>，则使用该接口，否则使用Equals() 来比较序列的元素。允许回退到Equals() 让它工作，例如除了我的业务对象之外，还有ObservableCollection<string>。

现在，我的单元测试中的断言是

Assert.IsTrue(expected.IsEquivalentTo(actual));

Answer 2

关于不为可变类型重载== 的 MSDN 文档是错误的。可变类型实现相等语义绝对没有错。两个项目现在可以相等，即使它们将来会改变。

可变类型和相等性的危险通常在它们被用作哈希表中的键或允许可变成员参与GetHashCode 函数时出现。

Answer 3

查看Eric Lippert 的Guidelines and rules for GetHashCode。

规则：当对象包含在依赖于哈希码保持稳定的数据结构中时，GetHashCode 返回的整数不能改变

虽然很危险，但允许对象的哈希码值随着对象的字段发生变异而发生变异。

Answer 4

我不明白你对GetHashCode 对HashSet 的担忧。 GetHashCode 只返回一个帮助HashSet 在内部存储和查找值的数字。如果对象的哈希码发生变化，该对象不会从HashSet 中删除，它就不会存储在最佳位置。

编辑

感谢@Erik J，我明白了。

HashSet<T> 是一个性能集合，要实现该性能，它完全依赖于GetHashCode 在集合的生命周期内保持不变。如果您想要这种性能，那么您需要遵循这些规则。如果您不能，那么您将不得不切换到其他内容，例如 List<T>