《Effective java》读书记录-第11条-谨慎地覆盖clone

Cloneable接口的目的是作为对象的一个mixin接口（mixin interface），表明这样的对象允许克隆（clone）。

Object的clone方法是受保护的。如果不借助与反射（reflection ），就不能仅仅因为一个对象实现了Cloneable，就可以调用clone方法。即使是反射调用也可能会失败，因为不能保证该对象一定具有可访问的clone方法。

既然Cloneable并没有包含任何方法，那么它到底有什么作用呢？

它决定了Object中受保护的clone方法实现的行为：如果一个类实现了Cloneable，Object的clone方法就返回该对象的逐域拷贝，否则就返回CloneNotSupportException异常。这是接口的一种极端非典型的用法，不值得效仿。通常情况下，实现接口是为了表明类可以为它的客户做些什么。然而，对于Cloneable接口，它改变了超类中受保护的方法的行为。

如果实现Cloneable接口是要对某个类起到作用，类和它的所有超类都必须遵守一个相当复杂的、不可实施的，并且基本上没有文档说明的协议。由此得到一种语言之外的机制：无需调用构造器就可以创建对象。

下面的代码是在第九条的PhoneNumber中加入了clone方法。

@Override
    public PhoneNumber clone() throws CloneNotSupportedException {
        return (PhoneNumber) super.clone();
    }

这里的返回类型是PhoneNumber而不是Object，是合法的。在JAVA1.5引入了协变返回类型（convariant return type）作为泛型（目前覆盖方法的返回类型可以是被覆盖方法的返回类型的子类型）。这里体现了： 永远不要让客户去做任何类库能够替客户完成的事情。

如果对象中包含的域引用了可变的对象，如果使用上述的方法做简单的clone将会导致灾难性的后果。例如第六条的Stack类，为了保证Stack的clone方法正常地工作，就需要拷贝Stack中的内部信息。

@Override
    public Stack clone() throws CloneNotSupportedException {
        Stack result= (Stack) super.clone();
        result.elements=elements.clone();
        return result;
    }

如果调用Stack类中的构造器，这种情况就不会发生。 实际上，clone方法就是另一个构造器；你必须确保它不会伤害到原始的对象，并确保正确地创建被克隆对象中的约束条件（ invariant）。

注意：

clone架构与引用可变对象的final域的正常用法是不兼容的。如果Stack.elements元素如果是final，那么clone方法就无法使用了。

clone方法的问题还有一大堆，以后再补充，看得有点晕也没太理解。

可以肯定的说，其他的接口都不应该扩展（extend）这个接口，为了继承而设计的类也不应该实现这个接口。由于它的缺点太多，有些专家级程序员干脆从来不去覆盖clone方法，也不去调用它，除非拷贝数组。你必须清楚一点，对于一个专门为继承而设计的类，如果你未能提供行为良好的受保护的clone方法，它的子类就不可能实现Cloneable接口。