我们是否需要在子类中甚至在Java中生成并序列化超类时都在子类中生成均值和哈希码？

如何解决我们是否需要在子类中甚至在Java中生成并序列化超类时都在子类中生成均值和哈希码？

我有一个名为User.java的类，代码如下，

public abstract class User implements Serializable {

   // serialVersionUID

   private Integer userId;
   private String userName;
   private String fullName;

   // Constructor()
   // Getters and Setters
   // equals()
   // hashCode()
}

我有Contact.java类，

public class Contact extends User {

   // serialVersionUID

   private String phoneNumber;
   private String address;

   // Constructor()
   // Getters and Setters
}

所以我的问题甚至是User类生成的equals和hashcode方法是否需要在Contact子类中再次重写它？

我也正在使用lombok，IDE是IntelliJ。我看到当我通过IDE生成equals和hashcode时，例如可以选择模板，

默认
像这样的Apache commons lang 3。

生成时，我看到生成的哈希码例如不同，

lombok包含不同的代码
Apache commons lang 3包含不同的代码

那么，两者之间有什么区别，每个生成的hascode（）之间有什么区别？

很抱歉，我在这种情况下缺乏知识。那么有人可以帮助我解决这个问题吗？预先感谢。

解决方法

通常，是的，但是首先您需要考虑相等性在User对象上下文中的含义。例如，我敢打赌，您会认为ID相等的任何用户都是相等的，并且没有必要或指向userName或fullName字段或{ {1}}字段。可能您只想检查phoneNumber，或者只检查userName和userId的组合。这与您要编写的代码无关，而与您考虑的任何两个给定用户对象之间的定义相等关系有关。

答案很复杂。

这个问题没有简单的答案。因此，让我们首先谈谈为什么您甚至想添加这样的方法。

什么是equals / hashCode

这两种方法的目的是使您能够使用userName类（或User类）的实例作为某种Contact中的键，或者将它们放在某些java.util.Map中，并让这些类型实际上满足其文档所告诉的内容。如果您将类型不包含equals / hashCode的对象添加到java.util.List上，然后在其上调用ArrayList，则它将无法实现您的预期。如果您尝试将它们用作地图中的键，它将无法正常工作。

因此，如果您不打算将User对象放入列表或地图中，则无需担心这些东西。根本不要编写方法。继续前进。

好的，但是我确实想这样做。

那使我们得以..

然后考虑您的类型实际代表什么

Contact类的实例实际代表什么？

它表示数据库中的一行（甚至可以是文本文件或基于非SQL的引擎）；例如，对对象的更改将导致对基础数据库的更改。
它表示用户通讯录中的联系人。不是“正在编写我的联系人应用程序正在使用的数据存储区”中的“通讯录”，而是“实际通讯录”。

根据您的答案，equals / hashCode将完全不同。

它代表数据库中的一行

对于基于SQL的数据库引擎，数据库引擎具有清晰且普遍理解的相等性定义。如果您说Contact实例代表数据库中的一行，那么逻辑上您的Java代码中的相等性定义必须与SQL的相等性定义相符，并且该定义就是这样：相等的主键？然后它们相等。

PK可以是任何值，并且可以是多列，但是绝大多数数据库设计都使用自动生成的单个数字列作为主键，并且假设您将“ userID”作为字段，这听起来像您的设计

这意味着您想要的平等的定义是：平等意味着：相同的用户ID 。但情况变得更糟：例如休眠状态下，您可以创建User的实例，并使该对象存在于Java内存中，而无需将其保存到DB中。这意味着（对于自动生成的主键），该对象有效地没有主键，并且对于两个没有主键的对象，即使它们在各个方面都完全相同，因此表示它们不相等-这是一个疯狂的相等性定义（如果userID字段相等，则相等，除非userID字段表示占位符，表示“尚未保存到数据库”，然后不相等），即使它们在各个方面都是相同的），则没有自动生成的工具可以实现此目的，则必须自己编写。

它代表通讯录中的一个条目

然后有效地颠倒了定义：联系人条目具有id是数据库的实现细节，并且是整个类中唯一不是概念的实际联系组成部分的字段，因此相等性是最好定义为：“相同，除了数据库ID之外，这无关紧要，因为它不是联系人的固有属性”。

同样，您需要在此处采取一些额外的操作； lombok，intellij，eclipse –所有这些工具都不知道其中的任何一个，并且默认情况下，您仅假设您打算两个实例相等，前提是每个字段相等。

嗯..我该如何选择？

好吧，回到equals / hashCode的含义是：使该对象的实例用作映射中的键以及.contains()的键，以便在将这些实例存储在Java列表中时给出正确的答案。因此，如果将两个contains的单独实例存储到一个列表中，它们在某种程度上都具有相同的ID，但具有不同的用户名值，您想怎么办？根据您的答案，您会知道这两种解释中的哪一种是正确的。

为什么这些工具会生成不同的hashCode提示？

他们没有。并不是的。 hashCode的要点很简单：

如果任意两个给定的对象具有不同的哈希码，则它们不可能相等。

就是这样。这就是全部。哈希码相等的两个对象不必相等（必须调用Contact才能找到），但是哈希码不相等的两个对象不相等，因此不需要调用{{ 1}}找出答案。这一点根本不是由Java强制执行的，但是您应该以这种方式编写（确保如果2个对象的哈希码不相等，则它们不能相等）。如果您不这样做，则类实例在用作例如哈希图中的键。

有很多方法可以编写导致这种效果的算法。这解释了为什么存在小的差异。但是，它们都是一样有效的（对于所有这些不同的工具，它们为已知的不同对象高效地生成不同的哈希码，并且对于所有这些不同的工具，hashCode方法的性能均差不多）。

子类型

就平等而言，子类型化非常复杂。这是由于Object的equals和hashCode javadoc中记录的规则所致。这个答案已经很长了，所以我不会解释为什么，所以您只需要进行一些网络搜索或相信我的话即可。但是，要求工具自动生成相等性/ hashCode意味着面对类型层次结构非常棘手。

听起来好像您想锁定a.equals(b)级别的相等性（因此，哈希码）意味着什么（即：平等性是通过具有相同的userID定义的。您的情况。但仅此而已），在这种情况下，您应该自己编写这些方法，它们应该是：

a.equals(b)

为什么？

这些方法通过“都具有一个用户ID，并且它们相等”来定义相等性。
它们与规则一致（例如：任意两个相等的对象必然具有相等的哈希码）。
它们很简单。
它们是“最终的”，因为否则它将变得异常复杂，并且由于class User必须与{{1相匹配的规则”，您不能允许子类型在您身上重新定义相等性，这是行不通的}}。
为什么使用public final boolean equals(Object other) { if (other == this) return true; if (this.userId == null) return false; if (!(other instanceof User) return false; return this.userId.equals(((User) other).userId); } public final int hashCode() { return userId == null ? System.identityHashCode() : 61 * userId.intValue(); }？这只是一个任意选择的质数。几乎任何数字都可以做到；在特殊情况下，任意质数的效率会非常非常非常高。

实际上我想要其他定义

然后使用lombok（免责声明：我是那里的核心贡献者，所以这是我对自己的评价），因为它具有最佳的equals实现，并且您不必查看或维护代码。使用a.equals(b)批注标记您的userId字段，使用b.equals(a)标记Contact类，使用61标记User（或包含@EqualsAndHashCode.Exclude的名称）-callSuper需要告诉lombok父类具有与lombok兼容的equals实现。