为什么 Java 不允许在 Enum 中重写 equals(Object) ？

Question

我注意到以下代码片段...

@Override
public boolean equals(Object otherObject) {
    ...
}

...不允许用于枚举，因为方法 equals(Object x) 在 final href="http://download.oracle.com/javase/6/docs/api/java/lang/Enum.html#equals%28java.lang.Object%29" rel="noreferrer">Enum< /代码>。为什么会这样呢？

我想不出任何需要覆盖 Enum 的 equals(Object) 的用例。我只是想知道这种行为背后的原因。

Answer 1

除了 return this == other 之外的任何内容都将违反直觉，并且违反最小惊讶原则。当且仅当两个枚举常量是同一个对象时，它们才应相等，并且覆盖此行为的能力很容易出错。

同样的推理也适用于 hashCode()、clone()、compareTo(Object)、name()、<代码>ordinal()和getDeclaringClass()。

---

JLS 并不促使选择将其定为最终版本，而是在枚举上下文中提到 equals 此处。片段：

Enum 中的 equals 方法是一个最终方法，它仅在其参数上调用 super.equals 并返回结果，从而执行身份比较。< /em>

Answer 2

对于enum的实例（值）相等意味着什么，已经提供了一个强烈直观的概念。允许重载 equals 方法会导致违反该概念，从而导致意外行为、错误等。

Answer 3

有时我们需要处理不符合Java命名标准的数据。如果能够做这样的事情那就太好了：

public enum Channel
{
    CallCenter("Call Center"),
    BankInternal("Bank Internal"),
    Branch("Branch");

    private final String value;

    Channel(String value)
    {
        this.value = value;
    }

    @Override
    public String toString()
    {
        return value;
    }

    public static Channel valueOf(String value)
    {
        for (Channel c : Channel.values())
            if (c.value.equals(value))
                return c;
        return null;
    }

    @Override
    public boolean equals(Object other) 
    {
        if (other instanceof String)
            other = Channel.valueOf((String)other);
        return super.equals(other);
    }
}

“String”类需要修改以适应......

public boolean equals (Object object) {
    if (object == this) return true;
    if (object instanceof Enum) 
        object = object.toString();
    if (object instanceof String) {
        String s = (String)object;
        // There was a time hole between first read of s.hashCode and second read
        //  if another thread does hashcode computing for incoming string object
        if (count != s.count ||
            (hashCode != 0 && s.hashCode != 0 && hashCode != s.hashCode))
                return false;
        return regionMatches(0, s, 0, count);
    }
    return false;
}

Answer 4

我会采纳大多数人的意见。如果禁止覆盖 Enum::equals，我认为这并不是遵循最小惊讶原则。我认为是为了不破坏Java。

在 JVM 和一些旧的类（例如 EnumMap）中，Enum 标识可以在内部使用 int 进行编码。例如，如果我们允许重写 Enum::equals，则 EnumMap会破坏Map的契约。

Answer 5

正是因为 Java 设计者无法想到任何可想象的重写 Enum.equals(Object) 的用例，所以该方法被声明为 Final - 因此这种重写是不可能的。

Answer 6

我必须承认枚举是我最不想重写的 equals() 。

我认为 equals() 在枚举中是最终的原因是 Java 鼓励 == 用于枚举比较，而枚举中 equals() 的实现只是使用它，因此允许 equals() 被覆盖是为了防止 >== 和 equals() 的行为不同，这是其他开发人员不会想到的。