我正在阅读有关如何正确执行数组深拷贝的信息,但是我对如何#clone()实现数组感到困惑。它是java.lang.Object该类的成员,但是,如果您阅读javadocs:
#clone()
java.lang.Object
首先,如果此对象的类未实现Cloneable接口,则将引发CloneNotSupportedException。
那么为什么要首先定义clone方法呢?当然,如果仅当存在接口时才可以使用方法,则可以将方法放在接口中。该Cloneable接口本身是空的; 它只是Java用来确保使用该clone方法合法的标记接口。
clone
Cloneable
以这种方式执行操作还消除了使用泛型来确保类型安全的能力:
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为什么要这样做?我敢肯定他们有正当的理由,但我似乎无法弄清楚。
Java中的克隆协定规定,每个clone实现都必须首先从中获取克隆的实例super.clone()。这将创建一条始终以对的调用结尾的链Object.clone,并且该方法包含“神奇的”本机级代码,该代码对struct表示Java对象的基础原始文件进行二进制复制。如果不存在该机制,clone则将不会是多态的:该Object.clone方法将生成所调用的任何类的实例;如果没有本地代码,则无法复制。
super.clone()
Object.clone
struct
这就是为什么Object.clone无法避免该方法的原因。Cloneable 本可以 包含一个clone方法,但是会产生有关该throws子句的问题。按照这种方式,您可以自由声明clone没有声明的异常,也可以声明任意的异常。如果该方法已经在接口中声明,则这种灵活性将是不可能的。
throws
请记住,泛型对于克隆几乎没有用:想象protected T clone()在Object:哪里会T来?我们是否需要Object<T>并强迫 Java Universe中的每个类都 对其自身进行参数化,而所有这些仅仅是为了使这种半不推荐使用的机制工作得更好一点?还请记住,此代码完全合法:
protected T clone()
Object
T
Object<T>
public class TheMightyOne implements Cloneable { @Override public TheMightyOne clone() { return (TheMightyOne) super.clone(); } }
您可以称之为:
TheMightyOne one = new TheMightyOne(); TheMightyOne two = one.clone(); // do downcasts needed