equals方法中身份测试的必要性

Question

编辑：问题的核心

身份测试何时会通过，而传统的 equals 方法的其余部分何时会失败？这是为了节省做额外工作的时间而添加的吗？

---

原帖

我在我正在测试的课程中使用来自org.apache.commons.lang3.builder.CompareToBuilder 的CompareToBuilder。我注意到 EqualsBuilder 需要在调用 equals 构建器之前显式调用以下代码。

if (obj == this) { return true; } // Identity test

这样的逻辑也出现在 Eclipse 自动生成的 equals 方法中。我试图通过让我的equals 方法简单地调用我的compareTo 方法并测试与0 的等效性来使用DRY 方法。

一个问题是我是否需要在我的 equals 方法中包含上面的代码，将它添加到我的 compareTo 方法中，或者它是否已经被 CompareToBuilder 覆盖。我注意到CompareToBuilder 检查传递的参数的等价性，但没有收到对原始 lhs（this）和 rhs（Object obj）的任何直接引用。这让我认为这是我应该在 compareTo 方法中纠正的疏忽。

我最大的问题是我似乎无法设计一个潜在的测试用例，其中obj == this 而是this.compareTo(obj) != 0。 唯一想到的是一个不正确实现的 compareTo，发送 obj如果不首先检查 this 中的相应变量是否也为空，则其实例变量之一 null 可能会返回一个非零数。 （昨天碰到这个）。

示例等于方法：

@Override
public boolean equals(Object obj) {
    if (obj != null && obj instanceof MyClass)
        return this.compareTo((MyClass)obj) == 0;
    return false;
}

示例 compareTo 方法

@Override
public int compareTo(MyClass other) {
return new CompareToBuilder()
    .append(this.getParam1(), other.getParam1())
    .append(this.getParam2(), other.getParam2())
    .toComparison();
}

Answer 1

查看Comparable、compareTo() 的文档需要这样做

x.compareTo(y) == -y.compareTo(x)

因此，如果x == y、x.compareTo(x) == -x.compareTo(x) 和因此x.compareTo(x) == 0。所以唯一的办法是让x == y && x.compareTo(y) != 0 打破compareTo() 合约。

请注意，据我了解，obj == this 测试倾向于添加到equals() 方法中，作为一种优化，以防止在不必要的情况下评估深度比较并且不影响调用结果。 （参见 Effective Java 第 2 版，第 8 条。）我假设这里的 compareTo() 方法也是如此。

Answer 2

身份测试何时会通过，而传统的 equals 方法的其余部分何时会失败？这是为了节省做额外工作的时间而添加的吗？

简短的回答是：从不。

身份测试是一种廉价的优化，旨在快速摆脱equals()方法的其余部分。事实上，Joshua Bloch 建议每个 equals() 方法都从优化之类的测试开始（Effective Java，第 2 版）。

先生。 Bloch 建议 equals() 采用以下通用结构：

1. 使用 == 运算符检查参数是否是对该对象的引用。如果是，则返回 true。

2. 使用 instanceof 运算符检查参数的类型是否正确。如果不是，则返回 false。

3. 将参数转换为正确的类型。

4. 对于类中的每个重要字段，检查参数的该字段是否与该对象的相应字段匹配。

5. 等等

Answer 3

当传统的 equals 失败时，身份测试何时通过？

从技术上讲，如果“传统”也意味着“天真”，那么其中包含循环的对象图（例如，A 有一个指向 B 的 ivar 有一个指向 A 的 ivar）将通过身份测试，但是传统的 equals 实现会进入无限循环。

我不确定 Apache 库是否可以防止这种情况发生。