?? chapter12.htm
字號:
<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=gb2312">
<title>Thinking in Java | Chinese Version by Trans Bot</title>
<meta name="Microsoft Theme" content="inmotion 111, default"></head>
<body background="../_themes/inmotion/inmtextb.gif" tppabs="http://member.netease.com/%7etransbot/Thinking%20in%20Java/_themes/inmotion/inmtextb.gif" bgcolor="#FFFFCC" text="#000000" link="#800000" vlink="#996633" alink="#FF3399">
<p>第12章 傳遞和返回對象<br>
<br>
到目前為止，讀者應對對象的“傳遞”有了一個較為深刻的認識，記住實際傳遞的只是一個句柄。<br>
在許多程序設計語言中，我們可用語言的“普通”方式到處傳遞對象，而且大多數時候都不會遇到問題。但有些時候卻不得不采取一些非常做法，使得情況突然變得稍微復雜起來（在C++中則是變得非常復雜）。Java亦不例外，我們十分有必要準確認識在對象傳遞和賦值時所發生的一切。這正是本章的宗旨。<br>
若讀者是從某些特殊的程序設計環境中轉移過來的，那么一般都會問到：“Java有指針嗎？”有些人認為指針的操作很困難，而且十分危險，所以一廂情愿地認為它沒有好處。同時由于Java有如此好的口碑，所以應該很輕易地免除自己以前編程中的麻煩，其中不可能夾帶有指針這樣的“危險品”。然而準確地說，Java是有指針的！事實上，Java中每個對象（除基本數據類型以外）的標識符都屬于指針的一種。但它們的使用受到了嚴格的限制和防范，不僅編譯器對它們有“戒心”，運行期系統也不例外。或者換從另一個角度說，Java有指針，但沒有傳統指針的麻煩。我曾一度將這種指針叫做“句柄”，但你可以把它想像成“安全指針”。和預備學校為學生提供的安全剪刀類似——除非特別有意，否則不會傷著自己，只不過有時要慢慢來，要習慣一些沉悶的工作。<br>
<br>
12.1 傳遞句柄<br>
將句柄傳遞進入一個方法時，指向的仍然是相同的對象。一個簡單的實驗可以證明這一點（若執行這個程序時有麻煩，請參考第3章3.1.2小節“賦值”）：<br>
<br>
542頁程序<br>
<br>
toString方法會在打印語句里自動調用，而PassHandles直接從Object繼承，沒有toString的重新定義。因此，這里會采用toString的Object版本，打印出對象的類，接著是那個對象所在的位置（不是句柄，而是對象的實際存儲位置）。輸出結果如下：<br>
p inside main(): PassHandles@1653748<br>
h inside f() : PassHandles@1653748<br>
可以看到，無論p還是h引用的都是同一個對象。這比復制一個新的PassHandles對象有效多了，使我們能將一個參數發給一個方法。但這樣做也帶來了另一個重要的問題。<br>
<br>
12.1.1 別名問題<br>
“別名”意味著多個句柄都試圖指向同一個對象，就象前面的例子展示的那樣。若有人向那個對象里寫入一點什么東西，就會產生別名問題。若其他句柄的所有者不希望那個對象改變，恐怕就要失望了。這可用下面這個簡單的例子說明：<br>
<br>
543頁程序<br>
<br>
對下面這行：<br>
Alias1 y = x; // Assign the handle<br>
它會新建一個Alias1句柄，但不是把它分配給由new創建的一個新鮮對象，而是分配給一個現有的句柄。所以句柄x的內容——即對象x指向的地址——被分配給y，所以無論x還是y都與相同的對象連接起來。這樣一來，一旦x的i在下述語句中增值：<br>
x.i++;<br>
y的i值也必然受到影響。從最終的輸出就可以看出：<br>
<br>
544頁上程序<br>
<br>
此時最直接的一個解決辦法就是干脆不這樣做：不要有意將多個句柄指向同一個作用域內的同一個對象。這樣做可使代碼更易理解和調試。然而，一旦準備將句柄作為一個自變量或參數傳遞——這是Java設想的正常方法——別名問題就會自動出現，因為創建的本地句柄可能修改“外部對象”（在方法作用域之外創建的對象）。下面是一個例子：<br>
<br>
544頁程序<br>
<br>
輸出如下：<br>
x: 7<br>
Calling f(x)<br>
x: 8<br>
<br>
方法改變了自己的參數——外部對象。一旦遇到這種情況，必須判斷它是否合理，用戶是否愿意這樣，以及是不是會造成問題。<br>
通常，我們調用一個方法是為了產生返回值，或者用它改變為其調用方法的那個對象的狀態（方法其實就是我們向那個對象“發一條消息”的方式）。很少需要調用一個方法來處理它的參數；這叫作利用方法的“副作用”（Side
Effect）。所以倘若創建一個會修改自己參數的方法，必須向用戶明確地指出這一情況，并警告使用那個方法可能會有的后果以及它的潛在威脅。由于存在這些混淆和缺陷，所以應該盡量避免改變參數。<br>
若需在一個方法調用期間修改一個參數，且不打算修改外部參數，就應在自己的方法內部制作一個副本，從而保護那個參數。本章的大多數內容都是圍繞這個問題展開的。<br>
<br>
12.2 制作本地副本<br>
稍微總結一下：Java中的所有自變量或參數傳遞都是通過傳遞句柄進行的。也就是說，當我們傳遞“一個對象”時，實際傳遞的只是指向位于方法外部的那個對象的“一個句柄”。所以一旦要對那個句柄進行任何修改，便相當于修改外部對象。此外：<br>
■參數傳遞過程中會自動產生別名問題<br>
■不存在本地對象，只有本地句柄<br>
■句柄有自己的作用域，而對象沒有<br>
■對象的“存在時間”在Java里不是個問題<br>
■沒有語言上的支持（如常量）可防止對象被修改（以避免別名的副作用）<br>
若只是從對象中讀取信息，而不修改它，傳遞句柄便是自變量傳遞中最有效的一種形式。這種做非常恰當；默認的方法一般也是最有效的方法。然而，有時仍需將對象當作“本地的”對待，使我們作出的改變只影響一個本地副本，不會對外面的對象造成影響。許多程序設計語言都支持在方法內自動生成外部對象的一個本地副本（注釋①）。盡管Java不具備這種能力，但允許我們達到同樣的效果。<br>
<br>
①：在C語言中，通常控制的是少量數據位，默認操作是按值傳遞。C++也必須遵照這一形式，但按值傳遞對象并非肯定是一種有效的方式。此外，在C++中用于支持按值傳遞的代碼也較難編寫，是件讓人頭痛的事情。<br>
<br>
12.2.1 按值傳遞<br>
首先要解決術語的問題，最適合“按值傳遞”的看起來是自變量。“按值傳遞”以及它的含義取決于如何理解程序的運行方式。最常見的意思是獲得要傳遞的任何東西的一個本地副本，但這里真正的問題是如何看待自己準備傳遞的東西。對于“按值傳遞”的含義，目前存在兩種存在明顯區別的見解：<br>
(1) Java按值傳遞任何東西。若將基本數據類型傳遞進入一個方法，會明確得到基本數據類型的一個副本。但若將一個句柄傳遞進入方法，得到的是句柄的副本。所以人們認為“一切”都按值傳遞。當然，這種說法也有一個前提：句柄肯定也會被傳遞。但Java的設計方案似乎有些超前，允許我們忽略（大多數時候）自己處理的是一個句柄。也就是說，它允許我們將句柄假想成“對象”，因為在發出方法調用時，系統會自動照管兩者間的差異。<br>
(2) Java主要按值傳遞（無自變量），但對象卻是按引用傳遞的。得到這個結論的前提是句柄只是對象的一個“別名”，所以不考慮傳遞句柄的問題，而是直接指出“我準備傳遞對象”。由于將其傳遞進入一個方法時沒有獲得對象的一個本地副本，所以對象顯然不是按值傳遞的。Sun公司似乎在某種程度上支持這一見解，因為它“保留但未實現”的關鍵字之一便是byvalue（按值）。但沒人知道那個關鍵字什么時候可以發揮作用。<br>
盡管存在兩種不同的見解，但其間的分歧歸根到底是由于對“句柄”的不同解釋造成的。我打算在本書剩下的部分里回避這個問題。大家不久就會知道，這個問題爭論下去其實是沒有意義的——最重要的是理解一個句柄的傳遞會使調用者的對象發生意外的改變。<br>
<br>
12.2.2 克隆對象<br>
若需修改一個對象，同時不想改變調用者的對象，就要制作該對象的一個本地副本。這也是本地副本最常見的一種用途。若決定制作一個本地副本，只需簡單地使用clone()方法即可。Clone是“克隆”的意思，即制作完全一模一樣的副本。這個方法在基礎類Object中定義成“protected”（受保護）模式。但在希望克隆的任何衍生類中，必須將其覆蓋為“public”模式。例如，標準庫類Vector覆蓋了clone()，所以能為Vector調用clone()，如下所示：<br>
<br>
547頁程序<br>
<br>
clone()方法產生了一個Object，后者必須立即重新造型為正確類型。這個例子指出Vector的clone()方法不能自動嘗試克隆Vector內包含的每個對象——由于別名問題，老的Vector和克隆的Vector都包含了相同的對象。我們通常把這種情況叫作“簡單復制”或者“淺層復制”，因為它只復制了一個對象的“表面”部分。實際對象除包含這個“表面”以外，還包括句柄指向的所有對象，以及那些對象又指向的其他所有對象，由此類推。這便是“對象網”或“對象關系網”的由來。若能復制下所有這張網，便叫作“全面復制”或者“深層復制”。<br>
在輸出中可看到淺層復制的結果，注意對v2采取的行動也會影響到v：<br>
<br>
548頁上程序<br>
<br>
一般來說，由于不敢保證Vector里包含的對象是“可以克隆”（注釋②）的，所以最好不要試圖克隆那些對象。<br>
<br>
②：“可以克隆”用英語講是cloneable，請留意Java庫中專門保留了這樣的一個關鍵字。<br>
<br>
12.2.3 使類具有克隆能力<br>
盡管克隆方法是在所有類最基本的Object中定義的，但克隆仍然不會在每個類里自動進行。這似乎有些不可思議，因為基礎類方法在衍生類里是肯定能用的。但Java確實有點兒反其道而行之；如果想在一個類里使用克隆方法，唯一的辦法就是專門添加一些代碼，以便保證克隆的正常進行。<br>
<br>
1. 使用protected時的技巧<br>
為避免我們創建的每個類都默認具有克隆能力，clone()方法在基礎類Object里得到了“保留”（設為protected）。這樣造成的后果就是：對那些簡單地使用一下這個類的客戶程序員來說，他們不會默認地擁有這個方法；其次，我們不能利用指向基礎類的一個句柄來調用clone()（盡管那樣做在某些情況下特別有用，比如用多形性的方式克隆一系列對象）。在編譯期的時候，這實際是通知我們對象不可克隆的一種方式——而且最奇怪的是，Java庫中的大多數類都不能克隆。因此，假如我們執行下述代碼：<br>
Integer x = new Integer(l);<br>
x = x.clone();<br>
那么在編譯期，就有一條討厭的錯誤消息彈出，告訴我們不可訪問clone()——因為Integer并沒有覆蓋它，而且它對protected版本來說是默認的）。<br>
但是，假若我們是在一個從Object衍生出來的類中（所有類都是從Object衍生的），就有權調用Object.clone()，因為它是“protected”，而且我們在一個繼承器中。基礎類clone()提供了一個有用的功能——它進行的是對衍生類對象的真正“按位”復制，所以相當于標準的克隆行動。然而，我們隨后需要將自己的克隆操作設為public，否則無法訪問。總之，克隆時要注意的兩個關鍵問題是：幾乎肯定要調用super.clone()，以及注意將克隆設為public。<br>
有時還想在更深層的衍生類中覆蓋clone()，否則就直接使用我們的clone()（現在已成為public），而那并不一定是我們所希望的（然而，由于Object.clone()已制作了實際對象的一個副本，所以也有可能允許這種情況）。protected的技巧在這里只能用一次：首次從一個不具備克隆能力的類繼承，而且想使一個類變成“能夠克隆”。而在從我們的類繼承的任何場合，clone()方法都是可以使用的，因為Java不可能在衍生之后反而縮小方法的訪問范圍。換言之，一旦對象變得可以克隆，從它衍生的任何東西都是能夠克隆的，除非使用特殊的機制（后面討論）令其“關閉”克隆能力。<br>
<br>
2. 實現Cloneable接口<br>
為使一個對象的克隆能力功成圓滿，還需要做另一件事情：實現Cloneable接口。這個接口使人稍覺奇怪，因為它是空的！<br>
interface Cloneable {}<br>
之所以要實現這個空接口，顯然不是因為我們準備上溯造型成一個Cloneable，以及調用它的某個方法。有些人認為在這里使用接口屬于一種“欺騙”行為，因為它使用的特性打的是別的主意，而非原來的意思。Cloneable
interface的實現扮演了一個標記的角色，封裝到類的類型中。<br>
兩方面的原因促成了Cloneable interface的存在。首先，可能有一個上溯造型句柄指向一個基礎類型，而且不知道它是否真的能克隆那個對象。在這種情況下，可用instanceof關鍵字（第11章有介紹）調查句柄是否確實同一個能克隆的對象連接：<br>
?? 快捷鍵說明
復制代碼
Ctrl + C
搜索代碼
Ctrl + F
全屏模式
F11
切換主題
Ctrl + Shift + D
顯示快捷鍵
?
增大字號
Ctrl + =
減小字號
Ctrl + -