为什么在Object中定义了equals和hashCode?

vbe*_*nar 15 java oop equals hashcode

决定在java.lang.Object中包含这些方法的原因是什么?对于许多类来说,平等和散列是没有意义的.

制作两个接口更合乎逻辑:

interface Equalable {
    boolean equals(Equalable other);
}

interface Hashable extends Equalable {
    int hashCode();
}
Run Code Online (Sandbox Code Playgroud)

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

class HashSet<T extends Hashable> ...
Run Code Online (Sandbox Code Playgroud)

它可以防止常见的初学者错误之一 - 使用一组项而不实现equals/hashCode.

Kow*_*ser 14

当我们实施Interface我们inject (or accept)的接口定义的合同.

Equalable&Hashable是两个不同的合同.但是,如果我们仔细观察,那么我们将看到它们彼此依赖,这意味着它们是a的一部分single interface,类似于EqualableAndHashable.

现在显而易见的问题是,它们是否应该成为这个新EqualableAndHashable界面的一部分或者Object

我们来看看.我们必须== (equal operator)检查两个对象的相等性.==运算符确认两个不同的基元/对象的值/引用是否相等.但这并不总是可以通过与==操作员核实来回答.

现在的问题是,这个相等是否which is also a contract应该通过接口或Object类的一部分注入?

如果我们看看,我们不能只说:

TypeX 不保证平等合同.

如果某些对象类型提供相等性而某些对象类型不提供,则会变得混乱.这意味着对象TypeX必须遵守对所有其他对象类型都适用的平等契约.因此,它不能从接口注入相等性,因为默认情况下,相等应该是任何对象的合同的一部分,否则会产生混乱.

所以我们需要Objects来实现equals.但它不能只实现equals方法,它还需要实现该hashcode方法.

  • `=`实际上是赋值运算符;) (2认同)
  • 我不明白你提到的"混乱".我一直实现这些方法在集合和地图中使用我的类.对我来说,不惜一切代价避免默认实现会更简单,所以我要从Object中删除这些方法.:d (2认同)