WrongClone類揭示了實現克隆的一種不正確途徑。它確實覆蓋了Object.clone()，并將那個方法設為public，但卻沒有實現Cloneable。所以一旦發出對super.clone()的調用（由于對Object.clone()的一個調用造成的），便會無情地擲出CloneNotSupportedException違例。<br>
在IsCloneable中，大家看到的才是進行克隆的各種正確行動：先覆蓋clone()，并實現了Cloneable。但是，這個clone()方法以及本例的另外幾個方法并不捕獲CloneNotSupportedException違例，而是任由它通過，并傳遞給調用者。隨后，調用者必須用一個try-catch代碼塊把它包圍起來。在我們自己的clone()方法中，通常需要在clone()內部捕獲CloneNotSupportedException違例，而不是任由它通過。正如大家以后會理解的那樣，對這個例子來說，讓它通過是最正確的做法。<br>
類NoMore試圖按照Java設計者打算的那樣“關閉”克隆：在衍生類clone()中，我們擲出CloneNotSupportedException違例。TryMore類中的clone()方法正確地調用super.clone()，并解析成NoMore.clone()，后者擲出一個違例并禁止克隆。<br>
但在已被覆蓋的clone()方法中，假若程序員不遵守調用super.clone()的“正確”方法，又會出現什么情況呢？在BackOn中，大家可看到實際會發生什么。這個類用一個獨立的方法duplicate()制作當前對象的一個副本，并在clone()內部調用這個方法，而不是調用super.clone()。違例永遠不會產生，而且新類是可以克隆的。因此，我們不能依賴“擲”出一個違例的方法來防止產生一個可克隆的類。唯一安全的方法在ReallyNoMore中得到了演示，它設為final，所以不可繼承。這意味著假如clone()在final類中擲出了一個違例，便不能通過繼承來進行修改，并可有效地禁止克隆（不能從一個擁有任意繼承級數的類中明確調用Object.clone()；只能調用super.clone()，它只可訪問直接基礎類）。因此，只要制作一些涉及安全問題的對象，就最好把那些類設為final。<br>
在類CheckCloneable中，我們看到的第一個類是tryToClone()，它能接納任何Ordinary對象，并用instanceof檢查它是否能夠克隆。若答案是肯定的，就將對象造型成為一個IsCloneable，調用clone()，并將結果造型回Ordinary，最后捕獲有可能產生的任何違例。請注意用運行期類型鑒定（見第11章）打印出類名，使自己看到發生的一切情況。<br>
在main()中，我們創建了不同類型的Ordinary對象，并在數組定義中上溯造型成為Ordinary。在這之后的頭兩行代碼創建了一個純粹的Ordinary對象，并試圖對其克隆。然而，這些代碼不會得到編譯，因為clone()是Object中的一個protected（受到保護的）方法。代碼剩余的部分將遍歷數組，并試著克隆每個對象，分別報告它們的成功或失敗。輸出如下：<br>
<br>
567-568頁程序<br>
<br>
總之，如果希望一個類能夠克隆，那么：<br>
(1) 實現Cloneable接口<br>
(2) 覆蓋clone()<br>
(3) 在自己的clone()中調用super.clone()<br>
(4) 在自己的clone()中捕獲違例<br>
這一系列步驟能達到最理想的效果。<br>
<br>
12.3.1 副本構建器<br>
克隆看起來要求進行非常復雜的設置，似乎還該有另一種替代方案。一個辦法是制作特殊的構建器，令其負責復制一個對象。在C++中，這叫作“副本構建器”。剛開始的時候，這好象是一種非常顯然的解決方案（如果你是C++程序員，這個方法就更顯親切）。下面是一個實際的例子：<br>
<br>
568-571頁程序<br>
<br>
這個例子第一眼看上去顯得有點奇怪。不同水果的質量肯定有所區別，但為什么只是把代表那些質量的數據成員直接置入Fruit（水果）類？有兩方面可能的原因。第一個是我們可能想簡便地插入或修改質量。注意Fruit有一個protected（受到保護的）addQualities()方法，它允許衍生類來進行這些插入或修改操作（大家或許會認為最合乎邏輯的做法是在Fruit中使用一個protected構建器，用它獲取FruitQualities參數，但構建器不能繼承，所以不可在第二級或級數更深的類中使用它）。通過將水果的質量置入一個獨立的類，可以得到更大的靈活性，其中包括可以在特定Fruit對象的存在期間中途更改質量。<br>
之所以將FruitQualities設為一個獨立的對象，另一個原因是考慮到我們有時希望添加新的質量，或者通過繼承與多形性改變行為。注意對GreenZebra來說（這實際是西紅柿的一類——我已栽種成功，它們簡直令人難以置信），構建器會調用addQualities()，并為其傳遞一個ZebraQualities對象。該對象是從FruitQualities衍生出來的，所以能與基礎類中的FruitQualities句柄聯系在一起。當然，一旦GreenZebra使用FruitQualities，就必須將其下溯造型成為正確的類型（就象evaluate()中展示的那樣），但它肯定知道類型是ZebraQualities。<br>
大家也看到有一個Seed（種子）類，Fruit（大家都知道，水果含有自己的種子）包含了一個Seed數組。<br>
最后，注意每個類都有一個副本構建器，而且每個副本構建器都必須關心為基礎類和成員對象調用副本構建器的問題，從而獲得“深層復制”的效果。對副本構建器的測試是在CopyConstructor類內進行的。方法ripen()需要獲取一個Tomato參數，并對其執行副本構建工作，以便復制對象：<br>
t = new Tomato(t);<br>
而slice()需要獲取一個更常規的Fruit對象，而且對它進行復制：<br>
f = new Fruit(f);<br>
它們都在main()中伴隨不同種類的Fruit進行測試。下面是輸出結果：<br>
<br>
572頁上程序<br>
<br>
從中可以看出一個問題。在slice()內部對Tomato進行了副本構建工作以后，結果便不再是一個Tomato對象，而只是一個Fruit。它已丟失了作為一個Tomato（西紅柿）的所有特征。此外，如果采用一個GreenZebra，ripen()和slice()會把它分別轉換成一個Tomato和一個Fruit。所以非常不幸，假如想制作對象的一個本地副本，Java中的副本構建器便不是特別適合我們。<br>
<br>
1. 為什么在C++的作用比在Java中大？<br>
副本構建器是C++的一個基本構成部分，因為它能自動產生對象的一個本地副本。但前面的例子確實證明了它不適合在Java中使用，為什么呢？在Java中，我們操控的一切東西都是句柄，而在C++中，卻可以使用類似于句柄的東西，也能直接傳遞對象。這時便要用到C++的副本構建器：只要想獲得一個對象，并按值傳遞它，就可以復制對象。所以它在C++里能很好地工作，但應注意這套機制在Java里是很不通的，所以不要用它。<br>
<br>
12.4 只讀類<br>
盡管在一些特定的場合，由clone()產生的本地副本能夠獲得我們希望的結果，但程序員（方法的作者）不得不親自禁止別名處理的副作用。假如想制作一個庫，令其具有常規用途，但卻不能擔保它肯定能在正確的類中得以克隆，這時又該怎么辦呢？更有可能的一種情況是，假如我們想讓別名發揮積極的作用——禁止不必要的對象復制——但卻不希望看到由此造成的副作用，那么又該如何處理呢？<br>
一個辦法是創建“不變對象”，令其從屬于只讀類。可定義一個特殊的類，使其中沒有任何方法能造成對象內部狀態的改變。在這樣的一個類中，別名處理是沒有問題的。因為我們只能讀取內部狀態，所以當多處代碼都讀取相同的對象時，不會出現任何副作用。<br>
作為“不變對象”一個簡單例子，Java的標準庫包含了“封裝器”（wrapper）類，可用于所有基本數據類型。大家可能已發現了這一點，如果想在一個象Vector（只采用Object句柄）這樣的集合里保存一個int數值，可以將這個int封裝到標準庫的Integer類內部。如下所示：<br>
<br>
573頁中程序<br>
<br>
Integer類（以及基本的“封裝器”類）用簡單的形式實現了“不變性”：它們沒有提供可以修改對象的方法。<br>
若確實需要一個容納了基本數據類型的對象，并想對基本數據類型進行修改，就必須親自創建它們。幸運的是，操作非常簡單：<br>
<br>
573-574頁程序<br>
<br>
注意n在這里簡化了我們的編碼。<br>
若默認的初始化為零已經足夠（便不需要構建器），而且不用考慮把它打印出來（便不需要toString），那么IntValue甚至還能更加簡單。如下所示：<br>
class IntValue { int n; }<br>
將元素取出來，再對其進行造型，這多少顯得有些笨拙，但那是Vector的問題，不是IntValue的錯。<br>
<br>
12.4.1 創建只讀類<br>
完全可以創建自己的只讀類，下面是個簡單的例子：<br>
<br>
574-575頁程序<br>
<br>
所有數據都設為private，可以看到沒有任何public方法對數據作出修改。事實上，確實需要修改一個對象的方法是quadruple()，但它的作用是新建一個Immutable1對象，初始對象則是原封未動的。<br>
方法f()需要取得一個Immutable1對象，并對其采取不同的操作，而main()的輸出顯示出沒有對x作任何修改。因此，x對象可別名處理許多次，不會造成任何傷害，因為根據Immutable1類的設計，它能保證對象不被改動。<br>
<br>
12.4.2 “一成不變”的弊端<br>
從表面看，不變類的建立似乎是一個好方案。但是，一旦真的需要那種新類型的一個修改的對象，就必須辛苦地進行新對象的創建工作，同時還有可能涉及更頻繁的垃圾收集。對有些類來說，這個問題并不是很大。但對其他類來說（比如String類），這一方案的代價顯得太高了。<br>
為解決這個問題，我們可以創建一個“同志”類，并使其能夠修改。以后只要涉及大量的修改工作，就可換為使用能修改的同志類。完事以后，再切換回不可變的類。<br>
因此，上例可改成下面這個樣子：<br>
<br>
575-577頁程序<br>
<br>
和往常一樣，Immutable2包含的方法保留了對象不可變的特征，只要涉及修改，就創建新的對象。完成這些操作的是add()和multiply()方法。同志類叫作Mutable，它也含有add()和multiply()方法。但這些方法能夠修改Mutable對象，而不是新建一個。除此以外，Mutable的一個方法可用它的數據產生一個Immutable2對象，反之亦然。<br>
兩個靜態方法modify1()和modify2()揭示出獲得同樣結果的兩種不同方法。在modify1()中，所有工作都是在Immutable2類中完成的，我們可看到在進程中創建了四個新的Immutable2對象（而且每次重新分配了val，前一個對象就成為垃圾）。<br>
在方法modify2()中，可看到它的第一個行動是獲取Immutable2 y，然后從中生成一個Mutable（類似于前面對clone()的調用，但這一次創建了一個不同類型的對象）。隨后，用Mutable對象進行大量修改操作，同時用不著新建許多對象。最后，它切換回Immutable2。在這里，我們只創建了兩個新對象（Mutable和Immutable2的結果），而不是四個。<br>
這一方法特別適合在下述場合應用：<br>
(1) 需要不可變的對象，而且<br>
(2) 經常需要進行大量修改，或者<br>
(3) 創建新的不變對象代價太高<br>
<br>
12.4.3 不變字串<br>
請觀察下述代碼：<br>
<br>
577-578頁程序<br>
<br>
q傳遞進入upcase()時，它實際是q的句柄的一個副本。該句柄連接的對象實際只在一個統一的物理位置處。句柄四處傳遞的時候，它的句柄會得到復制。<br>
若觀察對upcase()的定義，會發現傳遞進入的句柄有一個名字s，而且該名字只有在upcase()執行期間才會存在。upcase()完成后，本地句柄s便會消失，而upcase()返回結果——還是原來那個字串，只是所有字符都變成了大寫。當然，它返回的實際是結果的一個句柄。但它返回的句柄最終是為一個新對象的，同時原來的q并未發生變化。所有這些是如何發生的呢？<br>
<br>
1. 隱式常數<br>
若使用下述語句：<br>
String s = &quot;asdf&quot;;<br>
String x = Stringer.upcase(s);<br>
那么真的希望upcase()方法改變自變量或者參數嗎？我們通常是不愿意的，因為作為提供給方法的一種信息，自變量一般是拿給代碼的讀者看的，而不是讓他們修改。這是一個相當重要的保證，因為它使代碼更易編寫和理解。<br>
為了在C++中實現這一保證，需要一個特殊關鍵字的幫助：const。利用這個關鍵字，程序員可以保證一個句柄（C++叫“指針”或者“引用”）不會被用來修改原始的對象。但這樣一來，C++程序員需要用心記住在所有地方都使用const。這顯然易使人混淆，也不容易記住。<br>
<br>
2. 覆蓋&quot;+&quot;和StringBuffer<br>
利用前面提到的技術，String類的對象被設計成“不可變”。若查閱聯機文檔中關于String類的內容（本章稍后還要總結它），就會發現類中能夠修改String的每個方法實際都創建和返回了一個嶄新的String對象，新對象里包含了修改過的信息——原來的String是原封未動的。因此，Java里沒有與C++的const對應的特性可用來讓編譯器支持對象的不可變能力。若想獲得這一能力，可以自行設置，就象String那樣。<br>
由于String對象是不可變的，所以能夠根據情況對一個特定的String進行多次別名處理。因為它是只讀的，所以一個句柄不可能會改變一些會影響其他句柄的東西。因此，只讀對象可以很好地解決別名問題。<br>
通過修改產生對象的一個嶄新版本，似乎可以解決修改對象時的所有問題，就象String那樣。但對某些操作來講，這種方法的效率并不高。一個典型的例子便是為String對象覆蓋的運算符“+”。“覆蓋”意味著在與一個特定的類使用時，它的含義已發生了變化（用于String的“+”和“+=”是Java中能被覆蓋的唯一運算符，Java不允許程序員覆蓋其他任何運算符——注釋④）。<br>
<br>
④：C++允許程序員隨意覆蓋運算符。由于這通常是一個復雜的過程（參見《Thinking 
in C++》，Prentice-Hall于1995年出版），所以Java的設計者認定它是一種“糟糕”的特性，決定不在Java中采用。但具有諷剌意味的是，運算符的覆蓋在Java中要比在C++中容易得多。<br>
<br>
針對String對象使用時，“+”允許我們將不同的字串連接起來：<br>
<br>