随着时间的推移，类的演变是否会影响 equals 的实现？

Question

如果我们有一个类在创建时就实现了equals和hashCode。后来，该类通过新字段进行了增强，当这种情况发生时，很可能equals/hashCode也应该更新。我的问题是这是一种反模式吗？是否可能存在一些问题，例如，如果该类位于某个库中，并且有一些代码考虑旧合同？

Answer 1

是的，在修改任何实现时这是一个问题。

当开发人员使用您的类型时，他们将根据当前合同进行开发。如果更新实施不会改变合同，那就没问题。

但是，如果更新实现确实改变了合同，那就不好了。

---

如果您的平等合同目前是：

“如果两个对象具有相同的名称，那么它们是相等的”

如果两个对象具有相同的名称，则它们应该始终相等，因为开发人员将基于此进行开发。

例如，如果您引入一个新字段，id并更新合约以包含该字段：

“如果两个对象具有相同的名称和 ID，则它们相等”

如果两个对象共享相同的名称但具有不同的 id，则期望名称相等的系统现在将崩溃。

这不是那个开发商的错。你的合同规定平等是由名字决定的。他们的代码遵守了这一点。通过更新合同，您可能会破坏他们的代码。

---

如果您的合同规定：

“如果两个对象的所有属性都相等，那么它们就相等”

那么引入新属性不应该破坏软件，因为开发人员希望实现能够考虑到任何新属性，并且会在开发系统时考虑到这一点。

Answer 2

如果班级平等的契约发生变化，它们就需要更新，是的。假设您添加middleName到一个User类，并且您希望基于名字、中间名和姓氏进行平等，而不仅仅是名字和姓氏。但是，添加不影响平等的字段不需要更改。

唯一涉及的代码是equals()和中的代码hashcode()，因此除非您编写了一些糟糕的代码（例如不使用equals，而是手动比较字段），否则任何现有代码都会透明地工作。

Answer 3

我不认为这是反模式。您所描述的是程序代码是如何演变的。课程得到更新，提供更多功能和错误修复。

在您的情况下， hashCode 通常用于检查对象相等性，就像 equals 方法的实现一样。假设旧代码使用了整个类属性的一部分，则相等性检查应保持不变，因为旧代码不知道新属性，并且这些属性未在任何对象中分配。

然而，当一个类被更新并被无法测试的第三方代码使用时（例如，该类是在maven存储库中发布的maven项目的一部分），第三方代码应该使用该类/项目的版本以确保兼容性。就我个人而言，我见过很多情况，maven 项目被更新，新版本包含完全相同的类/方法签名，但实现完全不同，从而破坏了代码。