所有类都应该有.equals和.hashcode方法吗？

我正在研究assert调用.equals方法的单元测试项目。然而之前项目中的人员并未产生这些方法。所有类都应该有.equals和.hashcode方法吗？

在您编码时自动生成这些方法是否被认为是最佳实践？所有的编码员都应该这样做吗？

我在寻找关于.equals和.hashcode方法的更多信息，其中大部分似乎都是关于如何实现或覆盖它们。

2017-05-26 Ej_840

取决于班级的目的。对于许多类来说，由'Object'继承的'equals'和'hashCode'方法实现的“identity”就好了。 – Henry

如果您需要比较这些类型的对象，那么当您将对象放入哈希映射中时（通常情况下不需要），通常需要重写'equals'，并且'hashCode'和'hashCode'通常需要重写。。通常如果一个被覆盖，另一个也被覆盖。 – SomeDude

*自动生成* equals方法永远不是好习惯。很少的类通过所有的状态字段在逻辑上定义它们的身份，我认为这是自动生成的“等号”方法所能做的。如果要检查实例是否相等，请手动编写明智的equals方法和hashCode方法。 – VGR

这主要是一个品味问题 - 如果你不希望使用equals方法（例如，不使用assertEquals，绝不意味着使用这个类作为Map等中的关键字），写出它意味着你可能会写死代码，有些约定会主张避免它。

在这里，似乎没有问题 - 如果您打算使用assertEquals，则需要执行equals方法。如果你要实现它，你可能还应该实现hashCode以便将来验证你的代码不被偷偷摸摸，难以发现的bug。

2017-05-26 15:46:47 Mureinik

你似乎认为OP的测试中断言的期望与他的类从Object继承的equals（）实现不一致。从这个问题来看，我不清楚这是否属实。 –

“如果您打算使用assertEquals，则需要执行equals方法。”为什么会这样？如果'equals'预计会检查身份并因此未被覆盖，那么仍然可以使用'assertEquals'。 – Kapep

这完全不是“味道问题”。 “味道”与它毫无关系。这是无效的建议。这是一个语义问题，完全由工程原理决定。当然没有像“品味”那样模糊和难以界定。 –

自动生成这些方法使我们得到了一些标准的实现。一个标准实现在Object中进行编码：比较链接和本机哈希码计算。除非您可以想象其他标准实现适合项目中的所有实体，否则您可能不会自动生成equals和hash代码：当您知道未来比较的所有条件时，请手动实施它。

2017-05-26 15:51:18 basme

回答