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

VS2005文档重载 Equals() 和运算符 == 的指南（C# 编程指南） http://msdn.microsoft.com/en-us/library/ms173147%28v=vs.80%29.aspx部分状态

不建议在非不可变类型中重写运算符 ==。

较新的 .NET Framework 4 文档实现等于和等于运算符 (==) 的指南 http://msdn.microsoft.com/en-us/library/7h9bszxx%28v=vs.100%29.aspx尽管社区内容中的一篇文章重复了该断言并引用了旧文档，但省略了该声明。

看来，至少对于一些简单的可变类，重写 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() and operator==对于非不可变类型？

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

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

UPDATE

刚刚遇到这个in MSDN http://msdn.microsoft.com/en-us/library/dd183755.aspx

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

我开始意识到，根据上下文，我希望“等于”具有两种不同的含义。在权衡此处的输入以及here https://stackoverflow.com/questions/9707918/simplify-overriding-equals-gethashcode-in-c-sharp-for-better-maintainabilit，针对我的具体情况，我决定如下：

我没有凌驾于一切之上Equals() and GetHashCode()，而是保留共同但绝不是普遍存在的惯例Equals()意味着类的身份平等，并且Equals()意味着结构体的值相等。这一决定的最大驱动因素是散列集合中对象的行为（Dictionary<T,U>, HashSet<T>，...）如果我偏离了这个惯例。

这个决定让我仍然错过了价值平等的概念（如MSDN 上讨论过 http://msdn.microsoft.com/en-us/library/dd183755.aspx)

当你定义一个类或结构时，你决定它是否有意义 创建值相等（或等价）的自定义定义 方式。通常，当以下对象时，您可以实现值相等 类型预计会被添加到某种集合中，或者当 它们的主要目的是存储一组字段或属性。

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

Given

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)

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

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

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