5

我知道已经有很多关于 GetHashCode 的讨论，但他们通常提供的建议对于解决应该是一个相对简单的问题并不是很有帮助......

我有一个简单的 DTO 类，其中包含许多不同类型的自动实现属性，我想对这个类的两个实例执行一个简单的基于值的比较。（主要目的是确定在不同时间点生成的实例之间发生的任何变化。）

这可以通过添加适当的方法很容易地完成。但碰巧，这正是 Equals() 方法和 IEquatable 接口的用途。所以我认为，与其仅仅实现一个非标准的自定义方法，不如实现 IEquatable...

现在问题来了：MSDN 文档说，为了实现 IEquatable，您还应该重写 Object.Equals()。这是有道理的。但是如果你重写 Object.Equals()，你也应该重写 HetHashCode()。仍然不是一个真正的问题，我在这里找到了关于如何计算它的各种讨论，如果您决定这样做。

然而，我读过的文档和这里的所有讨论都说 GetHashCode() 输出应该保持稳定，因此不建议在可变对象上覆盖它......我可以理解这一点。（不过，请注意，我无意将此类用作字典键，这似乎是主要问题......）

但是我拥有的 DTO 类是可变的。使其不可变需要使用笨拙的构造函数或带有大量参数的静态工厂方法或构建器模式，并且会阻止您使用相当方便的对象初始化器语法。总而言之，这真的不值得付出努力和带来不便。

所以现在怎么办？我仍然想添加一种比较内容的方法，但现在我不太确定推荐的最佳做法是什么。

编辑：

忘了补充，我还看到了有关基于类中一组不可变字段实现 GetHashCode 的建议。然而，由于我所有的属性都是自动实现和可设置的，从技术上讲，它们都可以改变......

更新：

感谢您的回答。所以基本上我不需要太担心 GetHashCode，只要“我知道我在做什么”——这意味着该类不会在键控集合中使用。

还要感谢有关 IEqualityComparer 的建议，我可能会试一试。

选择“接受”的答案有点困难，因为它们都是很好的答案，但我必须选择一个......

4

2 回答 2

3

有人可能会说您的 DTO 根本不应该有任何行为，包括Equalsor GetHashCode。如果您想比较这些类型的对象，请使用您在其他地方定义的方法。这很好地解决了这个问题。

但是假设您对 DTO 没有那么严格，那么您必须覆盖Equals(Object). 你不一定要实现IEquatable，但如果你愿意，你可以。而且，是的，如果你 override Equals(Object)，那么你真的应该 override GetHashCode。

是的，GetHashCode依赖可变字段通常是个坏主意。但是，如果您不会使用键控集合中的对象，则不必担心。继续做你需要做的事。请记住：MSDN 中的指导方针是指导方针。如果您了解规则并了解违反规则的风险——并且你愿意承担后果——那么就去做吧。

于 2013-09-19T13:55:04.533 回答
0

只要将对象用作哈希表中的键，哈希码就需要稳定。如果你不使用它作为密钥，或者添加它之后不改变它，你就可以了。

如果您不将其用作哈希表键，则根本不需要覆盖GetHashCode。Resharper 可以生成所有相等的成员。这是我通常做的。

于 2013-09-19T14:04:20.487 回答