给定以下类别
public class Foo
{
public int FooId { get; set; }
public string FooName { get; set; }
public override bool Equals(object obj)
{
Foo fooItem = obj as Foo;
if (fooItem == null)
{
return false;
}
return fooItem.FooId == this.FooId;
}
public override int GetHashCode()
{
// Which is preferred?
return base.GetHashCode();
//return this.FooId.GetHashCode();
}
}
我重写了Equals方法，因为Foo表示Foos表的一行。哪个是重写GetHashCode的首选方法？
为什么重写GetHashCode很重要？
这并不一定重要；这取决于集合的大小和性能要求，以及您的类是否将用于您可能不知道性能要求的库中。我经常知道我的集合大小不是很大，我的时间比创建一个完美的哈希代码所获得的几微秒的性能更有价值；所以（为了消除编译器发出的恼人警告）我只需使用：
public override int GetHashCode()
{
return base.GetHashCode();
}
（当然，我也可以使用#pragma关闭警告，但我更喜欢这种方式。）
当然，当你处于一个你确实需要表现的位置时，这里其他人提到的所有问题都适用。最重要的是，否则在从哈希集或字典中检索项目时会得到错误的结果：哈希码不能随对象的生存时间而变化（更准确地说，在需要哈希码的时间，例如在字典中作为关键字时）：例如，以下内容是错误的，因为Value是公共的，因此可以在实例的生命周期内在类外部进行更改，因此不能将其用作哈希代码的基础：
class A
{
public int Value;
public override int GetHashCode()
{
return Value.GetHashCode(); //WRONG! Value is not constant during the instance's life time
}
}
另一方面，如果无法更改值，则可以使用：
class A
{
public readonly int Value;
public override int GetHashCode()
{
return Value.GetHashCode(); //OK Value is read-only and can't be changed during the instance's life time
}
}
只需补充以上答案：
如果不重写Equals，则默认行为是比较对象的引用。这同样适用于哈希码——默认实现通常基于引用的内存地址。因为您确实重写了Equals，这意味着正确的行为是比较您在Equals上实现的任何内容，而不是比较引用，所以您应该对哈希代码执行同样的操作。
您的类的客户端将期望哈希代码具有与equals方法类似的逻辑，例如，使用IEqualityComparer的linq方法首先比较哈希代码，只有当它们相等时，他们才会比较equals（）方法，如果我们不实现哈希代码，则该方法运行起来可能会更昂贵，equal对象可能会有不同的散列码（因为它们有不同的内存地址），并且会被错误地确定为不相等（Equals（）甚至不会命中）。
此外，除了在字典中使用对象时可能找不到对象的问题（因为它是由一个哈希码插入的，当你查找它时，默认的哈希码可能会不同，而且Equals（）甚至不会被调用，正如Marc Gravell在回答中解释的那样，您还引入了字典或哈希集概念的冲突，该概念不应允许相同的键-您已经声明，当重写Equals时，这些对象本质上是相同的，因此您不希望它们都作为数据结构上的不同键，而假设它们具有唯一键。但是因为它们有不同的哈希码，所以“相同”的密钥将被插入为不同的密钥。
