11.Override clone judiciously
大意为 明智地重写clone方法
说到clone方法，我们来提一提Cloneable这个接口，这个接口是用来作为一种标记某对象允许被clone的一种混合接口，可是不幸运的是，这个接口并没能起到该有的作用，它首要的缺陷就是缺少一个clone方法，并且Object的clone方法又是一个protected的方法。
你并不应该仅仅由于实现了Cloneable接口就去直接调用一个对象的clone方法。这样的调用经常会失败，我们并没有对能够调用这个方法有着足够的保证
除去这些问题和缺陷，我们还是必须好好地了解一下这个clone，毕竟用的过于广泛了
接下来我们来谈谈，关于这个方法该如何较好地实现，什么时候才被实现才是合适的，以及是否有其他的办法来替换
好，那么首先让我们来看看Cloneable这个接口究竟做了什么事？它确定了Object中对于clone方法的实现：如果一个类实现了Cloneable接口，Object的clone方法将会返回一个（field-by-field）域对域的复制对象 ; 否则，抛出一个CloneNotSupportedExeption的异常
一个接口这样被使用是极其罕见的，从未见过其他的接口有这样的作用
一般来说，实现一个接口是用来让这个能够做某些事情，而Cloneable则是修改了父类的protected方法的实现，如果实现Cloneable这个接口对于类有着什么作用的话，那么这个类和所有的父类都必须是相当复杂，不可强制执行，有着薄弱的协议的这样的类，这样所产生的结果将是超语言的（extralinguistic）：不通过构造函数直接创建对象
对于clone的规范也十分薄弱，下面从JavaSE8中复制一段过来
Creates and returns a copy of this object. The precise meaning of "copy" may depend on the class of the object. The general intent is that, for any object x, the expression:
x.clone() != x
will be true, and that the expression:
x.clone().getClass() == x.getClass()
will be true, but these are not absolute requirements. While it is typically the case that:
x.clone().equals(x)
will be true, this is not an absolute requirement.
比起JavaSE6中那一段
this is not an absolute requirement. Copying an object will typically entail creating a new instance of its class, but it may require copying of internal data structures as well. No constructors are called.
JavaSE8中添加了新的说明
By convention, the returned object should be obtained by calling super.clone. If a class and all of its superclasses (except Object) obey this convention, it will be the case that x.clone().getClass() == x.getClass().
By convention, the object returned by this method should be independent of this object (which is being cloned). To achieve this independence, it may be necessary to modify one or more fields of the object returned by super.clone before returning it. Typically, this means copying any mutable objects that comprise the internal "deep structure" of the object being cloned and replacing the references to these objects with references to the copies. If a class contains only primitive fields or references to immutable objects, then it is usually the case that no fields in the object returned by super.clone need to be modified.
The method clone for class Object performs a specific cloning operation. First, if the class of this object does not implement the interface Cloneable, then a CloneNotSupportedException is thrown. Note that all arrays are considered to implement the interface Cloneable and that the return type of the clone method of an array type T[] is T[] where T is any reference or primitive type. Otherwise, this method creates a new instance of the class of this object and initializes all its fields with exactly the contents of the corresponding fields of this object, as if by assignment; the contents of the fields are not themselves cloned. Thus, this method performs a "shallow copy" of this object, not a "deep copy" operation.
The class Object does not itself implement the interface Cloneable, so calling the clone method on an object whose class is Object will result in throwing an exception at run time.
更加严谨了，比起JavaSE6中不调用任何构造方法来创建对象来说看起来好像是比较严谨了，但还是没有解决问题，clone还是没有调用构造方法，一个好的clone方法应该调用构造方法来创建对象。如果一个类是final的话，那么调用clone就能绕过构造函数来创建新的对象了，显然太不合理了
按规定来说 x.clone().getClass() 应该和 x.getClass() 一般是一样的，然而，这有点弱
实践中，程序员们假定如果它们继承一个类并且调用父类的clone方法super.clone，那么返回的对象应该是子类的实例，父类提供这样功能的唯一方法就是返回一个通过调用super.clone获得的对象。如果clone方法返回一个通过构造方法创建出来的对象，通常会返回不一样的类，故如果你重写的是那些非final定义的类的clone方法的时候，你就应该在方法中返回通过调用super.clone获得的对象，如果所有类的父类都遵循这样的准则，那么调用super.clone最后就是调用到Object.clone方法，创建一个正确的类的实例
这种机制与自动构造函数链接非常相似，除非它不被强制执行
然而Cloneable接口没有这样做，在1.6版本中，详细说明了类在实现此接口时所承担的职责，实践中，一个类如果实现了Cloneable接口，就应该提供一个合适的public的clone方法，一般来说不可能这样做，除非所有的类的父类都对clone做出了不错的实现，不管是public或是protected的
假定你想在那些父类对clone方法有着良好实现的类上面来实现Cloneable这个接口，这个对象调用super.clone方法返回的不一定是你最后return的那个类，这取决于你的那些类的属性。从每一个父类的角度来看，它这个对象是对原始对象的完整复制
你的类中的域如果是值相关的，那么clone出来的这些域的值也都一样。如果你的类中的这些域都是基础类型或者是一些对于不可变对象的引用的话，那么clone返回的也就是你所需要的，没有必要去做其他的加工，举个例子，就我们之前使用过的PhoneNumber类，在之前的第9篇博客中有详细的描述，没有看过的读者可以去查看我的第九篇博客，我们为这个类实现cloneable接口，那么只需很简单的去调用父类的super.clone方法即可，如下
@Override
public PhoneNumber clone() {
try {
return (PhoneNumber) super.clone();
} catch(CloneNotSupportedException e) {
throw new AssertionError(); // Can't happen
}
}
需要说明的是，这里的clone方法将返回的是PhoneNumber这个类的实例，而不是Object，如果是在1.5版本中，这样做是合法的并且希望你去这么做，这被称为协变返回类型（covariant return types）在1.5版本中的generics部分被介绍
换句话说，现在对于重写的方法的返回类型是被重写的方法的返回类型的子类这样的是合法的，这就使得重写的方法能够对于返回的对象提供更多的信息，并且我们再也不用去强制转换了
但是呢，Object的clone方法返回的是Object的类型，所以我们在PhoneNumber的这个类中还是得将super.clone所返回的类型进行强制类型转换，变成PhoneNumber类，不过这样在每一次调用PhoneNumber.clone然后在return前就进行一次类型转换是更优的，比起需要我们每一次调用clone之后都要转换一次更优，符合这么一条原则：库可以做的事情绝对不要让用户去做
以上所谈的都是类的域为不变的，那么类的域如果动态分配的呢？显然用简单的clone是解决不了问题的，举个例子，在我的第六篇读书笔记中所提到的Stack类，一个栈
public class Stack {
private Object[] elements;
private int size = 0;
private static final int DEFAULT_INITIAL_CAPACITY = 16;
public Stack() {
this.elements = new Object[DEFAULT_INITIAL_CAPACITY];
}
public void push(Object e) {
ensureCapacity();
elements[size++] = e;
}
public Object pop() {
if (size == 0)
throw new EmptyStackException();
Object result = elements[--size];
elements[size] = null; // Eliminate obsolete reference
return result;
}
// Ensure space for at least one more element.
private void ensureCapacity() {
if (elements.length == size)
elements = Arrays.copyOf(elements, 2 * size + 1);
}
}
假定我们让这个栈的类实现Cloneable接口，并且我们简单地使用super.clone来返回的话，没错，我们的确可以得到一个大小上一模一样的一个栈的实例，但是需要注意的是，这个实例所拥有的引用都是和原来的实例所一致的，也就是说，我们操作这个新的实例的时候，不可避免地会影响到原来的那个实例，举个例子，我们利用clone创建了一个新的实例，然后在这个新的实例上进行pop弹出栈的操作，然后在原来的实例也进行pop弹出栈的操作，显然，在第二次弹出栈的时候，返回的是一个NULL，如果我们对这个原来的实例所弹出的对象进行操作的话，不可避免的会抛出一个空指针的异常
当然，上面这种情况如果我们使用构造函数来进行复制肯定就没有什么问题了，也由于上面这个问题，我们在实际中应该时刻注意clone方法所复制出来的实例对原来的实例是不能有任何影响的
下面给出对这个clone方法在Stack类上的正确实现
@Override public Stack clone() {
try {
Stack result = (Stack) super.clone();
result.elements = elements.clone();
return result;
} catch (CloneNotSupportedException e) {
throw new AssertionError();
}
}
在这里，我们对内部的数组进行了复制，你可能会好奇，数组并没有实现Cloneable接口，但是竟然能够进行clone方法的调用，原因就是这是JVM自己负责的，由它自由地实现，给出一段官方的示例代码
An array thus has the same public fields and methods as the following class:
class A<T> implements Cloneable, java.io.Serializable {
public final int length = X;
public T[] clone() {
try {
return (T[])super.clone();
} catch (CloneNotSupportedException e) {
throw new InternalError(e.getMessage());
}
}
}
Note that the cast to T[] in the code above would generate an unchecked warning (§5.1.9) if arrays were really implemented this way.
当然上述的解决方案解决不了当这些数组元素的域是final的情况，因为clone方法将会被禁止从原始的域分配给新的域，这就是一个比较重要的问题，clone并不能适用于那些可变域中的final域，除非这个可变的对象是安全地共享出来给clone的和原始的实例，当然为了让一个类变的可以Clone，你可以适当地修改域变为非final的
还需要提及的就是递归地调用clone并不足够，举个例子，假如你正在写一个hash table的类的clone方法，这个hash table有着一个数组用来存放bucket，这个数组的每一个元素都是拥有着键，值，以及指向下一个的引用，也就是每一个元素是一个链表，如果这个数组是空的那么就是NULL，在此我们不使用java给我们提供的列表的实现，也就是 java.util.LinkedList这个类
public class HashTable implements Cloneable {
private Entry[] buckets = ...;
private static class Entry {
final Object key;
Object value;
Entry next;
Entry(Object key, Object value, Entry next) {
this.key = key;
this.value = value;
this.next = next;
}
}
... // Remainder omitted
}
假如我们递归地使用clone方法,就像我们在Stack类里面重写的那样
// Broken - results in shared internal state!
@Override
public HashTable clone() {
try {
HashTable result = (HashTable) super.clone();
result.buckets = buckets.clone();
return result;
} catch (CloneNotSupportedException e) {
throw new AssertionError();
}
}
这样的话我们在clone的时候就会clone数组中的引用，也就造成了与原始的实例共享了这些引用，出现了相互的影响
为了解决这个问题，我们必须对链表进行重新的复制，下面给出代码:
public class HashTable implements Cloneable {
private Entry[] buckets = ...;
private static class Entry {
final Object key;
Object value;
Entry next;
Entry(Object key, Object value, Entry next) {
this.key = key;
this.value = value;
this.next = next;
}
// Recursively copy the linked list headed by this Entry
Entry deepCopy() {
return new Entry(key, value,
next == null ? null : next.deepCopy());
}
}
@Override
public HashTable clone() {
try {
HashTable result = (HashTable) super.clone();
result.buckets = new Entry[buckets.length];
for (int i = 0; i < buckets.length; i++)
if (buckets[i] != null)
result.buckets[i] = buckets[i].deepCopy();
return result;
} catch (CloneNotSupportedException e) {
throw new AssertionError();
}
}
... // Remainder omitted
}
在上述代码中，我们对每一个链表进行迭代，然后在复制，这样我们利用巧妙的函数递归成功复制了多个链表，这样的做法在数组长度不长的情况表现良好，但是对于每一个链表我们需要耗费一个栈帧，在链表长度足够长的时候，我们可能就会面临栈溢出的问题，如果改成迭代就没有这个问题了，如下：
// Iteratively copy the linked list headed by this Entry
Entry deepCopy() {
Entry result = new Entry(key, value, next);
for (Entry p = result; p.next != null; p = p.next)
p.next = new Entry(p.next.key, p.next.value, p.next.next);
return result;
}
还有一种方法就是先利用父类的方法也就是super.clone，然后在对每一个域运用更加高级的方法来重新刷新这些域，这样的方法十分优雅，但是优雅的方法通常速度不会很理想
和构造方法一样，一个clone方法不应该在clone的构造上调用任何非final方法，如果clone方法调用一个重写了的方法，这个方法将会在子类定义它之前执行，也就是说，这个方法很有可能会产生clone的实例与原始实例的冲突，因此，我们之前所谈论的put（key，value）方法应该要么是private的要么是final的
Object的clone方法被定义为是可以抛出一个CloneNotSupportedException的异常，但是我们去重写这个方法的话，就会忽略掉这个定义，public的clone方法应该忽略它，由于不去检查这个异常从而这个方法将更好地被使用，但是呢，如果一个类被设计为去继承并且重写这个clone方法，那就应该和Object的clone差不多了，应该被定义为protected，并且可以抛出一个CloneNotSupportedException的异常以及不去实现Cloneable的接口，这样就给了子类自由，让子类决定是否去实现cloneable接口
还需要提及的就是，当你想编写一个线程安全的类，并且这个类继承了Cloneable的接口的话，你就应该对clone方法进行同步的说明，也就是加上同步的关键字，在Object的clone方法中并没有进行同步，故那样是线程不安全的
说到这里，我们小总结一下，所有的类继承Cloneable接口，应该重写一个public的clone方法，并且返回自己类的类型实例，这个方法应该先调用super.clone，然后对该类的每个域进行调整，这就意味着，在对那些可变对象进行复制的时候，都是一次深拷贝，包括对许多引用的拷贝之类的，虽然我们可以递归地调用clone方法进行复制，但这并不是最好的方法，还有就是当一个类持有的域都是一些不变域或者是基本数据类型，我们进行clone的时候就不需要对这些域进行修正，当然，这里有些特例，举个例子，一个域代表一序列数值或者特殊的id，又或者是一个对象创建的次数之类的，对这些域就要进行修正
上述这些复杂的东西都是必要的吗？其实很少，如果你继承一个类，并实现了Cloneable的接口，你没有什么选择，只能去对clone方法进行好的实现，否则，你可以提供替代的复制方法，又或者是干脆不提供复制，举个例子，你没有必要为那些不可变对象提供复制的方法，因为复制出来的和原始的实例几乎是完全一样的
对于对象的复制一个更好的方法应该是复制构造方法（copy constructor）或者是复制工厂（copy factory）**，对于复制构造方法，它只是一个构造函数，它接受一个参数，其类型是包含构造函数的类，举个例子：
public Yum(Yum yum);
对于复制工厂，它就是复制构造函数的静态工厂模拟，举个例子：
public static Yum newInstance(Yum yum);
复制构造函数比起Cloneable/clone有着更多的优点，它们在创建对象时候并不会有风险，也就是我们之前所提到的final类利用clone可能会绕过构造方法来创建出新的对象；它们对于那些合理的final域并没有冲突；它们也不会抛出一些没有必要的异常；它们也不需要强制类型转换.....等等，比起Cloneable/clone来说真的是好太多了，然而把一个复制构造方法或者复制工厂放在接口里面是不可能的，Cloneable由于缺少一个public的clone方法而失去接口的作用，因此你并不会放弃接口而去使用复制构造函数或者是复制工厂
此外，一个复制构造函数或者复制工厂能够接受一个是这个类所实现的接口类型的参数，举个例子，按照惯例所有通用集合的实现都提供一个构造函数，其参数都是Collection或者Map类型。以接口为基的复制构造函数或者构造工厂，更加合适的叫法就是转换构造函数（conversion constructors）或者转换工厂（conversion factories），这样我们就可以选择复制的实例所实现的类型而不是强制用户使用原始实现的类型。假定你现在有一个HashSet s，你想要复制它并且变成一个TreeSet，对于clone方法来说难以实现，可是如果使用转换构造函数的话只需要：new TreeSet(s)
给出了Cloneable的这么多缺点，在使用的时候我们最好避免去使用它，接口最好不要去继承它，那些设计来被继承的类也最好不要实现这个接口
