为什么 Java 枚举不可克隆？

Question

现在改变问题已经太晚了，但更准确的是问“为什么clone()不允许单例？”。 copy() 方法会更方便。

---

Java 中的枚举不能被克隆有什么原因吗？

该手册指出

这保证了枚举永远不会被克隆，这是保持其“单例”状态所必需的。

但是返回实例本身也将保留其状态，并且我将能够像其他可克隆对象一样处理关联的枚举。

有人可能会争辩说

[clone()] 的一般意图是，对于任何对象 x，表达式： x.clone() != x 将为 true，[...]

但对于单例，相反，我希望 x.clone() == x 为 true 。如果返回实例本身，那么单例模式对于引用对象来说将是透明的。

那么，为什么在指定 clone() 时，枚举不允许被克隆，或者他们忘记考虑单例和不可变呢？

Answer 1

如果 x.clone() == x ，克隆单例的目的是什么？你不能直接使用x吗？

严格来说，如果您想克隆某些东西并强制x.clone() == x，则唯一可以作为克隆结果的对象是x 本身：

def clone() {
  return this;
}

这可能会产生误导...

---

如果您正在设计某些东西并基于 clone() 进行区分，那么恕我直言，您做错了...

Answer 2

如果您的克隆方法返回 this 实例而不是一个不同的对象，那么它就不是克隆，不是吗？

Javadoc 说：

按照约定，返回的对象
这个方法应该独立于
这个对象（正在被克隆）。

枚举不应该被克隆，因为每个值应该只有一个实例。

编辑：回应以下评论：

这正是我所批评的。为什么
不返回相同的实例，如果存在
不能是一个不同的吗？

因为这确实没有意义。如果它是同一个对象，那么它就不是克隆。 Javadoc 还说：

总体意图是，对于任何
对象x，表达式：

x.clone() != x

将为 true，并且
表达式：

x.clone().getClass() == x.getClass()

将为 true，但是这些
并非绝对要求。

因此，clone() 方法的目的是返回一个不同的对象。不幸的是，它说这不是绝对的要求，这使得您的建议有效，但我仍然认为这是不明智的，因为有一个返回 this 的克隆方法没有用。如果您正在做一些可疑的事情（例如在枚举常量中具有可变状态或对其进行同步），它甚至可能会导致问题。此类代码的行为会有所不同，具体取决于克隆方法是否进行了正确的克隆或仅返回 this。

当枚举本质上不可克隆时，您并没有真正解释为什么要将它们视为可克隆的。想要有一个不遵守公认约定的克隆方法似乎是为了解决您的方法中一些更基本的问题。

Answer 3

但对于单例，相反，我希望 x.clone() == x 为 true。

你可能想要，但我认为下面的代码会中断很奇怪：（

interface Foo extends Cloneable { public int getX(); public void setX(int x);  }
enum FooSingleton implements Foo { 
    INSTANCE; 
    private int x;
    public int getX(){ return x; }
    public void setX(int x){ this.x = x; }
}
class FooClass implements Foo { 
    private int x;
    public int getX(){ return x; }
    public void setX(int x){ this.x = x; }
}

boolean omg(Foo f){
    Foo c = f.clone();
    c.setX(c.getX() + 1);
    return c.getX() != f.getX();   
}
assert omg(new FooClass());        // OK
assert omg(FooSingleton.INSTANCE); // WTF?

当然，因为clone()只提供浅拷贝，即使是它的正确实现可能会导致上述代码中的错误。）

另一方面，我可以同意克隆操作对于不可变对象仅返回 this 是有意义的，并且枚举确实应该是不可变的。现在，当编写 clone() 的合约时，他们显然没有考虑不可变性，或者他们不想要语言不支持的概念的特殊情况（即不可变）类型）。

所以，clone() 就是它的本质，你不能很好地去改变自 Java 1.0 以来就存在的东西。我非常确定在某个地方，有一些代码完全依赖于 clone() 返回一个新的、不同的对象，也许作为 IdentityHashMap 或其他内容。

Answer 4

我猜他们不想在指定 clone() 时将单例视为特殊情况。这会使规范变得复杂。因此，现在库开发人员必须将它们视为特殊情况，但对于我们其他人来说，很高兴我们可以信任 x.clone() != x。

Answer 5

你自己对你的问题的回答就是最好的答案。一般来说，人们期望clone()返回一个不同的对象。这样一来，Cloneable 本身的语义就更有意义了。 （“该对象是可克隆的......哦，我必须能够复制。”）我无法立即想到这很重要的情况，但这就是 Cloneable 的预期语义含义。

我认为即使他们考虑单身，他们也不会改变它。毕竟，程序员有责任通过有选择地添加（并可能覆盖）Cloneable 接口来决定什么可以克隆、什么不能克隆，并且大多数程序员不会添加 也可以是单例的可克隆接口。

Answer 6

但对于单例，相反，我希望 x.clone() == x 为 true。

不，那不会是克隆人。所以，对于单身人士，你想要这样：

public Object clone() throws CloneNotSupportedException {
  throw new CloneNotSupportedException(); 
}