java 关于 equals 的最佳实践：超载还是不超载？

Best practices regarding equals: to overload or not to overload?

提问by polygenelubricants

Consider the following snippet:

考虑以下片段：

import java.util.*;
public class EqualsOverload {
    public static void main(String[] args) {
        class Thing {
            final int x;
            Thing(int x)          { this.x = x; }
            public int hashCode() { return x; }

            public boolean equals(Thing other) { return this.x == other.x; }
        }
        List<Thing> myThings = Arrays.asList(new Thing(42));
        System.out.println(myThings.contains(new Thing(42))); // prints "false"
    }
}

Note that containsreturns false!!! We seems to have lost our things!!

注意contains返回false！！！我们的东西好像丢了！！

The bug, of course, is the fact that we've accidentally overloaded, instead of overridden, Object.equals(Object). If we had written class Thingas follows instead, then containsreturns trueas expected.

当然，错误在于我们不小心重载了，而不是覆盖了, Object.equals(Object)。如果我们class Thing改为如下编写，contains则按true预期返回。

        class Thing {
            final int x;
            Thing(int x)          { this.x = x; }
            public int hashCode() { return x; }

            @Override public boolean equals(Object o) {
                return (o instanceof Thing) && (this.x == ((Thing) o).x);
            }
        }

Effective Java 2nd Edition, Item 36: Consistently use the Override annotation, uses essentially the same argument to recommend that @Overrideshould be used consistently. This advice is good, of course, for if we had tried to declare @Override equals(Thing other)in the first snippet, our friendly little compiler would immediately point out our silly little mistake, since it's an overload, not an override.

Effective Java 2nd Edition, Item 36: Consistently use the Override annotation，使用本质上相同的参数来推荐@Override应该一致使用。这个建议当然很好，因为如果我们试图@Override equals(Thing other)在第一个片段中声明，我们友好的小编译器会立即指出我们愚蠢的小错误，因为它是一个重载，而不是一个覆盖。

What the book doesn't specifically cover, however, is whether overloading equalsis a good idea to begin with. Essentially, there are 3 situations:

然而，这本书没有具体介绍的是，重载是否equals是一个好主意。本质上，有3种情况：

• Overload only, no override -- ALMOST CERTAINLY WRONG!
  • This is essentially the first snippet above
• Override only (no overload) -- one way to fix
  • This is essentially the second snippet above
• Overload and override combo -- another way to fix

• 仅过载，无覆盖——几乎肯定是错误的！
  • 这基本上是上面的第一个片段
• 仅覆盖（无过载）——一种修复方法
  • 这基本上是上面的第二个片段
• 重载和覆盖组合——另一种修复方法

The 3rd situation is illustrated by the following snippet:

以下代码段说明了第 3 种情况：

        class Thing {
            final int x;
            Thing(int x)          { this.x = x; }
            public int hashCode() { return x; }

            public boolean equals(Thing other) { return this.x == other.x; }
            @Override public boolean equals(Object o) {
                return (o instanceof Thing) && (this.equals((Thing) o));
            }
        }

Here, even though we now have 2 equalsmethod, there is still one equality logic, and it's located in the overload. The @Overridesimply delegates to the overload.

在这里，即使我们现在有 2 个equals方法，仍然有一个相等逻辑，它位于重载中。在@Override简单地委托给过载。

So the questions are:

所以问题是：

• What are the pros and cons of "override only" vs "overload & override combo"?
• Is there a justification for overloading equals, or is this almost certainly a bad practice?

• “仅覆盖”与“过载和覆盖组合”的优缺点是什么？
• 是否有理由重载equals，或者这几乎肯定是一种不好的做法？

采纳答案by b_erb

I'dont see the case for overloading equals, except that is more error-prone and harder to maintain, especially when using inheritance.

我没有看到重载 equals 的情况，除了它更容易出错且更难维护，尤其是在使用继承时。

Here, it can be extremly hard to maintain reflexivity, symmetry and transitivity or to detect their inconsistencies, because you always must be aware of the actual equals method that gets invoked. Just think of a large inheritance hierarchie and only some of the types implementing their own overloading method.

在这里，保持自反性、对称性和传递性或检测它们的不一致可能非常困难，因为您必须始终了解被调用的实际 equals 方法。想想一个大的继承层次结构，只有一些类型实现了自己的重载方法。

So I'd say just don't do it.

所以我会说不要这样做。

回答by aioobe

If you have one single field as in your example, I think

如果您在示例中只有一个字段，我认为

@Override public boolean equals(Object o) {
    return (o instanceof Thing) && (this.x == ((Thing) o).x);
}

is the way to go. Anything else would be overly complicated imo. But if you add a field (and don't want to pass the 80-column recommendation by sun) it would look something like

是要走的路。其他任何事情都会过于复杂。但是如果你添加一个字段（并且不想通过 sun 的 80 列推荐）它看起来像

@Override public boolean equals(Object o) {
    if (!(o instanceof Thing))
        return false;
    Thing t = (Thing) o;
    return this.x == t.x && this.y == t.y;
}

which I think is slightly uglier than

我认为这比

public boolean equals(Thing o) {
    return this.x == o.x && this.y == o.y;
}

@Override public boolean equals(Object o) {
    // note that you don't need this.equals().
    return (o instanceof Thing) && equals((Thing) o);
}

So my rule of thumb is basically, if need to cast it more than once in override-only, do the override-/overload-combo.

所以我的经验法则基本上是，如果需要在override-only 中多次投射它，请执行override-/overload-combo。

---

---

A secondaryaspect is the runtime overhead. As Java performance programming, Part 2: The cost of castingexplains:

甲次要方面是运行时开销。作为Java 性能编程，第 2 部分：转换的成本解释了：

Downcast operations(also called narrowing conversions in the Java Language Specification) convert an ancestor class reference to a subclass reference. This casting operation creates execution overhead, since Java requires that the cast be checked at runtime to make sure that it's valid.

向下转换操作（在 Java 语言规范中也称为缩小转换）将祖先类引用转换为子类引用。此转换操作会产生执行开销，因为 Java 要求在运行时检查转换以确保其有效。

By using the overload-/override-combo, the compiler will, in some cases (not all!) manage to do without the downcast.

通过使用重载/覆盖组合，编译器将在某些情况下（不是全部！）设法在没有向下转型的情况下进行。

---

---

To comment on @Snehal point, that exposing both methods possibly confuses client-side developers: Another option would be to let the overloaded equals be private. The elegance is preserved, the method can be used internally, while the interface to the client side looks as expected.

评论@Snehal 点，公开这两种方法可能会使客户端开发人员感到困惑：另一种选择是让重载的 equals 是私有的。优雅被保留，该方法可以在内部使用，而客户端的界面看起来像预期的那样。

回答by Snehal

Issues with Overloaded Equals:

重载等于的问题：

• All the Collections provided by Java ie; Set, List, Map use the overridden method for comparing two objects. So even if you overload the equals method, it doesn't solve the purpose of comparing two objects. Also, if you just overload and implement the hashcode method, it would result in erroneous behavior

• If you have both overloaded and overridden equals methods and exposing both these methods you are going to confuse the client side developers. It is by convention people believe that you are overriding the Object class

• Java ie 提供的所有集合；Set、List、Map 使用重写的方法来比较两个对象。所以即使你重载了equals方法，也不能解决比较两个对象的目的。另外，如果你只是重载并实现 hashcode 方法，它会导致错误的行为

• 如果您同时拥有重载和覆盖的 equals 方法并公开这两种方法，那么您将使客户端开发人员感到困惑。按照惯例，人们认为您正在覆盖 Object 类

回答by Bozho

There are a number of items in the book that cover this. (It's not in front of me, so I'll refer to items as I remember them)

书中有许多项目涵盖了这一点。（它不在我面前，所以我会参考我记得的物品）

There is en example exactly using equals(..)where it is said that overloading should not be used, and if used - it should be used with care. The item about method design warns against overloading methods with the same number of arguments. So - no, don't overload equals(..)

有一个确切使用的例子equals(..)，据说不应该使用重载，如果使用 - 应该小心使用。关于方法设计的条目警告不要重载具有相同数量参数的方法。所以 - 不，不要超载equals(..)

Update:From "Effective Java" (p.44)

更新：来自“Effective Java”（第 44 页）

It is acceptable to provide such a "strongly typed" equals method in addition tothe normal one as long as the two methods return the same result, but there is no compelling reason to do so.

除了正常的方法之外，还可以提供这样一种“强类型”的 equals 方法，只要这两种方法返回相同的结果，但没有令人信服的理由这样做。

So, it is not forbidden to do so, but it adds complexity to your class, while adding no gains.

因此，不禁止这样做，但它会增加您的类的复杂性，而不会增加任何收益。

回答by vbezhenar

I use this approach with override and overload combo in my projects, because code looks a bit cleaner. I didn't have problems with this approach so far.

我在我的项目中将这种方法与覆盖和重载组合一起使用，因为代码看起来更简洁一些。到目前为止，我对这种方法没有任何问题。

回答by AndreyMltln

Let me share an example of "buggy code" with Overloaded equals:

让我与 Overloaded equals 分享一个“错误代码”的例子：

class A{
    private int val;

    public A(int i){
        this.val = i;
    }

    public boolean equals(A a){
        return a.val == this.val;
    }

    @Override
    public int hashCode() {
        return Objects.hashCode(this.val);
    }
}

public class TestOverloadEquals {

    public static void main(String[] args){
        A a1 = new A(1), a2 = new A(2);
        List<A> list = new ArrayList<>();
        list.add(a1);
        list.add(a2);
        A a3 =  new A(1);

        System.out.println(list.contains(a3));
    }
}

回答by Marc

I can think of a very simple example where this won't work properly and why you should never do this:

我可以想到一个非常简单的例子，它不能正常工作，为什么你不应该这样做：

class A {
   private int x;

   public A(int x) {
       this.x = x;
   }

   public boolean equals(A other) {
       return this.x == other.x;
   }

   @Override
   public boolean equals(Object other) {
       return (other instanceof A) && equals((A) other);
   }
}

class B extends A{
    private int y;

    public B(int x, int y) {
        super(x);
        this.y = y;
    }

    public boolean equals(B other) {
        return this.equals((A)other) && this.y == other.y; 
    }

    @Override
    public boolean equals(Object other) {
        return (other instanceof B) && equals((B) other);
    }
}

public class Test {
    public static void main(String[] args) {
        A a = new B(1,1);
        B b1 = new B(1,1);
        B b2 = new B(1,2);

        // This obviously returns false
        System.out.println(b1.equals(b2));
        // What should this return? true!
        System.out.println(a.equals(b2));
        // And this? Also true!
        System.out.println(b2.equals(a));
    }
}

In this test, you can clearly see that the overloaded method does more harm than good when using inheritance. In both wrong cases the more generic equals(A a)is called, because the Java compiler only knows that ais of type Aand that object does not have the overloaded equals(B b)method.

在这个测试中，您可以清楚地看到重载方法在使用继承时弊大于利。在这两种错误的情况下，equals(A a)都会调用更通用的方法，因为 Java 编译器只知道它a的类型，A而该对象没有重载的equals(B b)方法。

Afterthought: making the overloaded equalsprivate does solve this problem, but was does that really gain you? It only adds an extra method, which can only be called by doing a cast.

事后思考：使重载equals私有确实解决了这个问题，但这真的让你受益吗？它只添加了一个额外的方法，只能通过强制转换来调用。