11.Override clone judiciously
大意為 明智地重寫clone方法
說(shuō)到clone方法，我們來(lái)提一提Cloneable這個(gè)接口，這個(gè)接口是用來(lái)作為一種標(biāo)記某對(duì)象允許被clone的一種混合接口，可是不幸運(yùn)的是，這個(gè)接口并沒能起到該有的作用，它首要的缺陷就是缺少一個(gè)clone方法，并且Object的clone方法又是一個(gè)protected的方法。
你并不應(yīng)該僅僅由于實(shí)現(xiàn)了Cloneable接口就去直接調(diào)用一個(gè)對(duì)象的clone方法。這樣的調(diào)用經(jīng)常會(huì)失敗，我們并沒有對(duì)能夠調(diào)用這個(gè)方法有著足夠的保證
除去這些問題和缺陷，我們還是必須好好地了解一下這個(gè)clone，畢竟用的過于廣泛了
接下來(lái)我們來(lái)談?wù)劊P(guān)于這個(gè)方法該如何較好地實(shí)現(xiàn)，什么時(shí)候才被實(shí)現(xiàn)才是合適的，以及是否有其他的辦法來(lái)替換
好，那么首先讓我們來(lái)看看Cloneable這個(gè)接口究竟做了什么事？它確定了Object中對(duì)于clone方法的實(shí)現(xiàn)：如果一個(gè)類實(shí)現(xiàn)了Cloneable接口，Object的clone方法將會(huì)返回一個(gè)（field-by-field）域?qū)τ虻膹?fù)制對(duì)象 ; 否則，拋出一個(gè)CloneNotSupportedExeption的異常
一個(gè)接口這樣被使用是極其罕見的，從未見過其他的接口有這樣的作用
一般來(lái)說(shuō)，實(shí)現(xiàn)一個(gè)接口是用來(lái)讓這個(gè)能夠做某些事情，而Cloneable則是修改了父類的protected方法的實(shí)現(xiàn)，如果實(shí)現(xiàn)Cloneable這個(gè)接口對(duì)于類有著什么作用的話，那么這個(gè)類和所有的父類都必須是相當(dāng)復(fù)雜，不可強(qiáng)制執(zhí)行，有著薄弱的協(xié)議的這樣的類，這樣所產(chǎn)生的結(jié)果將是超語(yǔ)言的（extralinguistic）：不通過構(gòu)造函數(shù)直接創(chuàng)建對(duì)象
對(duì)于clone的規(guī)范也十分薄弱，下面從JavaSE8中復(fù)制一段過來(lái)
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中添加了新的說(shuō)明
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.
更加嚴(yán)謹(jǐn)了，比起JavaSE6中不調(diào)用任何構(gòu)造方法來(lái)創(chuàng)建對(duì)象來(lái)說(shuō)看起來(lái)好像是比較嚴(yán)謹(jǐn)了，但還是沒有解決問題，clone還是沒有調(diào)用構(gòu)造方法，一個(gè)好的clone方法應(yīng)該調(diào)用構(gòu)造方法來(lái)創(chuàng)建對(duì)象。如果一個(gè)類是final的話，那么調(diào)用clone就能繞過構(gòu)造函數(shù)來(lái)創(chuàng)建新的對(duì)象了，顯然太不合理了
按規(guī)定來(lái)說(shuō) x.clone().getClass() 應(yīng)該和 x.getClass() 一般是一樣的，然而，這有點(diǎn)弱
實(shí)踐中，程序員們假定如果它們繼承一個(gè)類并且調(diào)用父類的clone方法super.clone，那么返回的對(duì)象應(yīng)該是子類的實(shí)例，父類提供這樣功能的唯一方法就是返回一個(gè)通過調(diào)用super.clone獲得的對(duì)象。如果clone方法返回一個(gè)通過構(gòu)造方法創(chuàng)建出來(lái)的對(duì)象，通常會(huì)返回不一樣的類，故如果你重寫的是那些非final定義的類的clone方法的時(shí)候，你就應(yīng)該在方法中返回通過調(diào)用super.clone獲得的對(duì)象，如果所有類的父類都遵循這樣的準(zhǔn)則，那么調(diào)用super.clone最后就是調(diào)用到Object.clone方法，創(chuàng)建一個(gè)正確的類的實(shí)例
這種機(jī)制與自動(dòng)構(gòu)造函數(shù)鏈接非常相似，除非它不被強(qiáng)制執(zhí)行
然而Cloneable接口沒有這樣做，在1.6版本中，詳細(xì)說(shuō)明了類在實(shí)現(xiàn)此接口時(shí)所承擔(dān)的職責(zé)，實(shí)踐中，一個(gè)類如果實(shí)現(xiàn)了Cloneable接口，就應(yīng)該提供一個(gè)合適的public的clone方法，一般來(lái)說(shuō)不可能這樣做，除非所有的類的父類都對(duì)clone做出了不錯(cuò)的實(shí)現(xiàn)，不管是public或是protected的
假定你想在那些父類對(duì)clone方法有著良好實(shí)現(xiàn)的類上面來(lái)實(shí)現(xiàn)Cloneable這個(gè)接口，這個(gè)對(duì)象調(diào)用super.clone方法返回的不一定是你最后return的那個(gè)類，這取決于你的那些類的屬性。從每一個(gè)父類的角度來(lái)看，它這個(gè)對(duì)象是對(duì)原始對(duì)象的完整復(fù)制
你的類中的域如果是值相關(guān)的，那么clone出來(lái)的這些域的值也都一樣。如果你的類中的這些域都是基礎(chǔ)類型或者是一些對(duì)于不可變對(duì)象的引用的話，那么clone返回的也就是你所需要的，沒有必要去做其他的加工，舉個(gè)例子，就我們之前使用過的PhoneNumber類，在之前的第9篇博客中有詳細(xì)的描述，沒有看過的讀者可以去查看我的第九篇博客，我們?yōu)檫@個(gè)類實(shí)現(xiàn)cloneable接口，那么只需很簡(jiǎn)單的去調(diào)用父類的super.clone方法即可，如下
@Override
public PhoneNumber clone() {
try {
return (PhoneNumber) super.clone();
} catch(CloneNotSupportedException e) {
throw new AssertionError(); // Can't happen
}
}
需要說(shuō)明的是，這里的clone方法將返回的是PhoneNumber這個(gè)類的實(shí)例，而不是Object，如果是在1.5版本中，這樣做是合法的并且希望你去這么做，這被稱為協(xié)變返回類型（covariant return types）在1.5版本中的generics部分被介紹
換句話說(shuō)，現(xiàn)在對(duì)于重寫的方法的返回類型是被重寫的方法的返回類型的子類這樣的是合法的，這就使得重寫的方法能夠?qū)τ诜祷氐膶?duì)象提供更多的信息，并且我們?cè)僖膊挥萌?qiáng)制轉(zhuǎn)換了
但是呢，Object的clone方法返回的是Object的類型，所以我們?cè)赑honeNumber的這個(gè)類中還是得將super.clone所返回的類型進(jìn)行強(qiáng)制類型轉(zhuǎn)換，變成PhoneNumber類，不過這樣在每一次調(diào)用PhoneNumber.clone然后在return前就進(jìn)行一次類型轉(zhuǎn)換是更優(yōu)的，比起需要我們每一次調(diào)用clone之后都要轉(zhuǎn)換一次更優(yōu)，符合這么一條原則：庫(kù)可以做的事情絕對(duì)不要讓用戶去做
以上所談的都是類的域?yàn)椴蛔兊模敲搭惖挠蛉绻麆?dòng)態(tài)分配的呢？顯然用簡(jiǎn)單的clone是解決不了問題的，舉個(gè)例子，在我的第六篇讀書筆記中所提到的Stack類，一個(gè)棧
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);
}
}
假定我們讓這個(gè)棧的類實(shí)現(xiàn)Cloneable接口，并且我們簡(jiǎn)單地使用super.clone來(lái)返回的話，沒錯(cuò)，我們的確可以得到一個(gè)大小上一模一樣的一個(gè)棧的實(shí)例，但是需要注意的是，這個(gè)實(shí)例所擁有的引用都是和原來(lái)的實(shí)例所一致的，也就是說(shuō)，我們操作這個(gè)新的實(shí)例的時(shí)候，不可避免地會(huì)影響到原來(lái)的那個(gè)實(shí)例，舉個(gè)例子，我們利用clone創(chuàng)建了一個(gè)新的實(shí)例，然后在這個(gè)新的實(shí)例上進(jìn)行pop彈出棧的操作，然后在原來(lái)的實(shí)例也進(jìn)行pop彈出棧的操作，顯然，在第二次彈出棧的時(shí)候，返回的是一個(gè)NULL，如果我們對(duì)這個(gè)原來(lái)的實(shí)例所彈出的對(duì)象進(jìn)行操作的話，不可避免的會(huì)拋出一個(gè)空指針的異常
當(dāng)然，上面這種情況如果我們使用構(gòu)造函數(shù)來(lái)進(jìn)行復(fù)制肯定就沒有什么問題了，也由于上面這個(gè)問題，我們?cè)趯?shí)際中應(yīng)該時(shí)刻注意clone方法所復(fù)制出來(lái)的實(shí)例對(duì)原來(lái)的實(shí)例是不能有任何影響的
下面給出對(duì)這個(gè)clone方法在Stack類上的正確實(shí)現(xiàn)
@Override public Stack clone() {
try {
Stack result = (Stack) super.clone();
result.elements = elements.clone();
return result;
} catch (CloneNotSupportedException e) {
throw new AssertionError();
}
}
在這里，我們對(duì)內(nèi)部的數(shù)組進(jìn)行了復(fù)制，你可能會(huì)好奇，數(shù)組并沒有實(shí)現(xiàn)Cloneable接口，但是竟然能夠進(jìn)行clone方法的調(diào)用，原因就是這是JVM自己負(fù)責(zé)的，由它自由地實(shí)現(xiàn)，給出一段官方的示例代碼
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.
當(dāng)然上述的解決方案解決不了當(dāng)這些數(shù)組元素的域是final的情況，因?yàn)閏lone方法將會(huì)被禁止從原始的域分配給新的域，這就是一個(gè)比較重要的問題，clone并不能適用于那些可變域中的final域，除非這個(gè)可變的對(duì)象是安全地共享出來(lái)給clone的和原始的實(shí)例，當(dāng)然為了讓一個(gè)類變的可以Clone，你可以適當(dāng)?shù)匦薷挠蜃優(yōu)榉莊inal的
還需要提及的就是遞歸地調(diào)用clone并不足夠，舉個(gè)例子，假如你正在寫一個(gè)hash table的類的clone方法，這個(gè)hash table有著一個(gè)數(shù)組用來(lái)存放bucket，這個(gè)數(shù)組的每一個(gè)元素都是擁有著鍵，值，以及指向下一個(gè)的引用，也就是每一個(gè)元素是一個(gè)鏈表，如果這個(gè)數(shù)組是空的那么就是NULL，在此我們不使用java給我們提供的列表的實(shí)現(xiàn)，也就是 java.util.LinkedList這個(gè)類
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方法,就像我們?cè)赟tack類里面重寫的那樣
// 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();
}
}
這樣的話我們?cè)赾lone的時(shí)候就會(huì)clone數(shù)組中的引用，也就造成了與原始的實(shí)例共享了這些引用，出現(xiàn)了相互的影響
為了解決這個(gè)問題，我們必須對(duì)鏈表進(jìn)行重新的復(fù)制，下面給出代碼:
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
}
在上述代碼中，我們對(duì)每一個(gè)鏈表進(jìn)行迭代，然后在復(fù)制，這樣我們利用巧妙的函數(shù)遞歸成功復(fù)制了多個(gè)鏈表，這樣的做法在數(shù)組長(zhǎng)度不長(zhǎng)的情況表現(xiàn)良好，但是對(duì)于每一個(gè)鏈表我們需要耗費(fèi)一個(gè)棧幀，在鏈表長(zhǎng)度足夠長(zhǎng)的時(shí)候，我們可能就會(huì)面臨棧溢出的問題，如果改成迭代就沒有這個(gè)問題了，如下：
// 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，然后在對(duì)每一個(gè)域運(yùn)用更加高級(jí)的方法來(lái)重新刷新這些域，這樣的方法十分優(yōu)雅，但是優(yōu)雅的方法通常速度不會(huì)很理想
和構(gòu)造方法一樣，一個(gè)clone方法不應(yīng)該在clone的構(gòu)造上調(diào)用任何非final方法，如果clone方法調(diào)用一個(gè)重寫了的方法，這個(gè)方法將會(huì)在子類定義它之前執(zhí)行，也就是說(shuō)，這個(gè)方法很有可能會(huì)產(chǎn)生clone的實(shí)例與原始實(shí)例的沖突，因此，我們之前所談?wù)摰膒ut（key，value）方法應(yīng)該要么是private的要么是final的
Object的clone方法被定義為是可以拋出一個(gè)CloneNotSupportedException的異常，但是我們?nèi)ブ貙戇@個(gè)方法的話，就會(huì)忽略掉這個(gè)定義，public的clone方法應(yīng)該忽略它，由于不去檢查這個(gè)異常從而這個(gè)方法將更好地被使用，但是呢，如果一個(gè)類被設(shè)計(jì)為去繼承并且重寫這個(gè)clone方法，那就應(yīng)該和Object的clone差不多了，應(yīng)該被定義為protected，并且可以拋出一個(gè)CloneNotSupportedException的異常以及不去實(shí)現(xiàn)Cloneable的接口，這樣就給了子類自由，讓子類決定是否去實(shí)現(xiàn)cloneable接口
還需要提及的就是，當(dāng)你想編寫一個(gè)線程安全的類，并且這個(gè)類繼承了Cloneable的接口的話，你就應(yīng)該對(duì)clone方法進(jìn)行同步的說(shuō)明，也就是加上同步的關(guān)鍵字，在Object的clone方法中并沒有進(jìn)行同步，故那樣是線程不安全的
說(shuō)到這里，我們小總結(jié)一下，所有的類繼承Cloneable接口，應(yīng)該重寫一個(gè)public的clone方法，并且返回自己類的類型實(shí)例，這個(gè)方法應(yīng)該先調(diào)用super.clone，然后對(duì)該類的每個(gè)域進(jìn)行調(diào)整，這就意味著，在對(duì)那些可變對(duì)象進(jìn)行復(fù)制的時(shí)候，都是一次深拷貝，包括對(duì)許多引用的拷貝之類的，雖然我們可以遞歸地調(diào)用clone方法進(jìn)行復(fù)制，但這并不是最好的方法，還有就是當(dāng)一個(gè)類持有的域都是一些不變域或者是基本數(shù)據(jù)類型，我們進(jìn)行clone的時(shí)候就不需要對(duì)這些域進(jìn)行修正，當(dāng)然，這里有些特例，舉個(gè)例子，一個(gè)域代表一序列數(shù)值或者特殊的id，又或者是一個(gè)對(duì)象創(chuàng)建的次數(shù)之類的，對(duì)這些域就要進(jìn)行修正
上述這些復(fù)雜的東西都是必要的嗎？其實(shí)很少，如果你繼承一個(gè)類，并實(shí)現(xiàn)了Cloneable的接口，你沒有什么選擇，只能去對(duì)clone方法進(jìn)行好的實(shí)現(xiàn)，否則，你可以提供替代的復(fù)制方法，又或者是干脆不提供復(fù)制，舉個(gè)例子，你沒有必要為那些不可變對(duì)象提供復(fù)制的方法，因?yàn)閺?fù)制出來(lái)的和原始的實(shí)例幾乎是完全一樣的
對(duì)于對(duì)象的復(fù)制一個(gè)更好的方法應(yīng)該是復(fù)制構(gòu)造方法（copy constructor）或者是復(fù)制工廠（copy factory）**，對(duì)于復(fù)制構(gòu)造方法，它只是一個(gè)構(gòu)造函數(shù)，它接受一個(gè)參數(shù)，其類型是包含構(gòu)造函數(shù)的類，舉個(gè)例子：
public Yum(Yum yum);
對(duì)于復(fù)制工廠，它就是復(fù)制構(gòu)造函數(shù)的靜態(tài)工廠模擬，舉個(gè)例子：
public static Yum newInstance(Yum yum);
復(fù)制構(gòu)造函數(shù)比起Cloneable/clone有著更多的優(yōu)點(diǎn)，它們?cè)趧?chuàng)建對(duì)象時(shí)候并不會(huì)有風(fēng)險(xiǎn)，也就是我們之前所提到的final類利用clone可能會(huì)繞過構(gòu)造方法來(lái)創(chuàng)建出新的對(duì)象；它們對(duì)于那些合理的final域并沒有沖突；它們也不會(huì)拋出一些沒有必要的異常；它們也不需要強(qiáng)制類型轉(zhuǎn)換.....等等，比起Cloneable/clone來(lái)說(shuō)真的是好太多了，然而把一個(gè)復(fù)制構(gòu)造方法或者復(fù)制工廠放在接口里面是不可能的，Cloneable由于缺少一個(gè)public的clone方法而失去接口的作用，因此你并不會(huì)放棄接口而去使用復(fù)制構(gòu)造函數(shù)或者是復(fù)制工廠
此外，一個(gè)復(fù)制構(gòu)造函數(shù)或者復(fù)制工廠能夠接受一個(gè)是這個(gè)類所實(shí)現(xiàn)的接口類型的參數(shù)，舉個(gè)例子，按照慣例所有通用集合的實(shí)現(xiàn)都提供一個(gè)構(gòu)造函數(shù)，其參數(shù)都是Collection或者M(jìn)ap類型。以接口為基的復(fù)制構(gòu)造函數(shù)或者構(gòu)造工廠，更加合適的叫法就是轉(zhuǎn)換構(gòu)造函數(shù)（conversion constructors）或者轉(zhuǎn)換工廠（conversion factories），這樣我們就可以選擇復(fù)制的實(shí)例所實(shí)現(xiàn)的類型而不是強(qiáng)制用戶使用原始實(shí)現(xiàn)的類型。假定你現(xiàn)在有一個(gè)HashSet s，你想要復(fù)制它并且變成一個(gè)TreeSet，對(duì)于clone方法來(lái)說(shuō)難以實(shí)現(xiàn)，可是如果使用轉(zhuǎn)換構(gòu)造函數(shù)的話只需要：new TreeSet(s)
給出了Cloneable的這么多缺點(diǎn)，在使用的時(shí)候我們最好避免去使用它，接口最好不要去繼承它，那些設(shè)計(jì)來(lái)被繼承的類也最好不要實(shí)現(xiàn)這個(gè)接口
