为什么在对象中定义equals和hashCode？

Question

决定将这些方法包含在java.lang.Object中的背后原因是什么？平等和哈希对于许多类没有意义。

建立两个接口将更加合乎逻辑：

interface Equalable {
    boolean equals(Equalable other);
}

interface Hashable extends Equalable {
    int hashCode();
}

例如，HashSet定义可能看起来像

class HashSet<T extends Hashable> ...

这将防止出现一个常见的初学者错误-使用项目集而不实现equals / hashCode。

Answer 1

当我们实现一个接口时，我们注入（或接受）该接口定义的合同。

Equalable＆Hashable是两个不同的合同。但是，如果我们仔细观察，就会发现它们彼此依赖，这意味着它们是的一部分single interface，类似EqualableAndHashable。

现在显而易见的问题是，它们是否应该成为此新EqualableAndHashable界面的一部分Object？

让我们找出答案。我们==（等于运算符）检查两个对象的相等性。==运算符确认两个不同图元/对象的值/引用是否相等。但这并不总是可能仅通过与==操作员确认来回答。

现在的问题是，是否应该通过接口或对象类的一部分来注入相等性（也就是契约）？

如果我们看一看，我们不能只说：

TypeX 不保证平等合同。

如果某些对象类型提供相等性而某些对象不提供相等性，则将变得混乱。这意味着of的对象TypeX必须遵守平等契约，这对于所有其他对象类型也是如此。因此，它绝不能从接口注入相等性，因为缺省情况下，相等性应该是任何对象的合同的一部分，否则它将造成混乱。

因此，我们需要Objects提出的实现equals。但是它不能仅实现equals方法，还需要实现hashcode方法。