为什么#clone（）不在Cloneable接口中？

一尘不染

为什么#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为什么要这样做？我敢肯定他们有正当的理由，但我似乎无法弄清楚。

阅读 285

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