小编典典

为什么#clone()不在Cloneable接口中?

java

我正在阅读有关如何正确执行数组深拷贝的信息,但是我对如何#clone()实现数组感到困惑。它是java.lang.Object该类的成员,但是,如果您阅读javadocs:

首先,如果此对象的类未实现Cloneable接口,则将引发CloneNotSupportedException。

那么为什么要首先定义clone方法呢?当然,如果仅当存在接口时才可以使用方法,则可以将方法放在接口中。该Cloneable接口本身是空的;
它只是Java用来确保使用该clone方法合法的标记接口。

以这种方式执行操作还消除了使用泛型来确保类型安全的能力:

class Foo implements Cloneable { // Valid.
    @Override
    public Object clone() throws CloneNotSupportedException {
        // ...
    }
}

class TypeSafeFoo implements Cloneable<TypeSafeFoo> { // Not valid.
    @Override
    public TypeSafeFoo clone() throws CloneNotSupportedException {
        // ...
    }
}

Java为什么要这样做?我敢肯定他们有正当的理由,但我似乎无法弄清楚。


阅读 357

收藏
2020-12-03

共1个答案

小编典典

Java中的克隆协定规定,每个clone实现都必须首先从中获取克隆的实例super.clone()。这将创建一条始终以对的调用结尾的链Object.clone,并且该方法包含“神奇的”本机级代码,该代码对struct表示Java对象的基础原始文件进行二进制复制。如果不存在该机制,clone则将不会是多态的:该Object.clone方法将生成所调用的任何类的实例;如果没有本地代码,则无法复制。

这就是为什么Object.clone无法避免该方法的原因。Cloneable 本可以
包含一个clone方法,但是会产生有关该throws子句的问题。按照这种方式,您可以自由声明clone没有声明的异常,也可以声明任意的异常。如果该方法已经在接口中声明,则这种灵活性将是不可能的。

请记住,泛型对于克隆几乎没有用:想象protected T clone()Object:哪里会T来?我们是否需要Object<T>并强迫
Java Universe中的每个类都 对其自身进行参数化,而所有这些仅仅是为了使这种半不推荐使用的机制工作得更好一点?还请记住,此代码完全合法:

public class TheMightyOne implements Cloneable {
   @Override public TheMightyOne clone() {
     return (TheMightyOne) super.clone();
   }
}

您可以称之为:

TheMightyOne one = new TheMightyOne();
TheMightyOne two = one.clone(); // do downcasts needed
2020-12-03