飛翔的起點(diǎn)

# re: java重載的解析 2007-12-13 13:44 cc

是java解惑吧，java疑惑，難道越看越疑惑啊。  回復(fù)  更多評(píng)論   

# re: java重載的解析 2007-12-18 18:54 forgood

是呀,我也感覺如此,但是細(xì)細(xì)看的話,會(huì)發(fā)現(xiàn)好多經(jīng)常遇到的問題,仔細(xì)的看看,可以鞏固\復(fù)習(xí)一些知識(shí),
共同進(jìn)步,
  回復(fù)  更多評(píng)論   

# re: java重載的解析[未登錄] 2007-12-19 09:22 ddpie

謎題46：令人混淆的構(gòu)造器案例
本謎題呈現(xiàn)給你了兩個(gè)容易令人混淆的構(gòu)造器。main方法調(diào)用了一個(gè)構(gòu)造器，但是它調(diào)用的到底是哪一個(gè)呢？該程序的輸出取決于這個(gè)問題的答案。那么它到底會(huì)打印出什么呢？甚至它是否是合法的呢？
public class Confusing {
private Confusing(Object o) {
System.out.println("Object");
}
private Confusing(double[] dArray) {
System.out.println("double array");
}
public static void main(String[] args) {
new Confusing(null);
}
}
傳遞給構(gòu)造器的參數(shù)是一個(gè)空的對(duì)象引用，因此，初看起來(lái)，該程序好像應(yīng)該調(diào)用參數(shù)類型為Object的重載版本，并且將打印出Object。另一方面，數(shù)組也是引用類型，因此null也可以應(yīng)用于類型為double[ ]的重載版本。你由此可能會(huì)得出結(jié)論：這個(gè)調(diào)用是模棱兩可的，該程序應(yīng)該不能編譯。如果你試著去運(yùn)行該程序，就會(huì)發(fā)現(xiàn)這些直觀感覺都是不對(duì)的：該程序打印的是double array。這種行為可能顯得有悖常理，但是有一個(gè)很好的理由可以解釋它。
Java的重載解析過(guò)程是以兩階段運(yùn)行的。第一階段選取所有可獲得并且可應(yīng)用的方法或構(gòu)造器。第二階段在第一階段選取的方法或構(gòu)造器中選取最精確的一個(gè)。如果一個(gè)方法或構(gòu)造器可以接受傳遞給另一個(gè)方法或構(gòu)造器的任何參數(shù)，那么我們就說(shuō)第一個(gè)方法比第二個(gè)方法缺乏精確性[JLS 15.12.2.5]。
在我們的程序中，兩個(gè)構(gòu)造器都是可獲得并且可應(yīng)用的。構(gòu)造器Confusing(Object)可以接受任何傳遞給Confusing(double[ ])的參數(shù)，因此Confusing(Object)相對(duì)缺乏精確性。（每一個(gè)double數(shù)組都是一個(gè)Object，但是每一個(gè)Object并不一定是一個(gè)double數(shù)組。）因此，最精確的構(gòu)造器就是Confusing(double[ ])，這也就解釋了為什么程序會(huì)產(chǎn)生這樣的輸出。
如果你傳遞的是一個(gè)double[ ]類型的值，那么這種行為是有意義的；但是如果你傳遞的是null，這種行為就有違直覺了。理解本謎題的關(guān)鍵在于在測(cè)試哪一個(gè)方法或構(gòu)造器最精確時(shí)，這些測(cè)試沒有使用實(shí)際的參數(shù)：即出現(xiàn)在調(diào)用中的參數(shù)。這些參數(shù)只是被用來(lái)確定哪一個(gè)重載版本是可應(yīng)用的。一旦編譯器確定了哪些重載版本是可獲得且可應(yīng)用的，它就會(huì)選擇最精確的一個(gè)重載版本，而此時(shí)使用的僅僅是形式參數(shù)：即出現(xiàn)在聲明中的參數(shù)。
要想用一個(gè)null參數(shù)來(lái)調(diào)用Confusing(Object)構(gòu)造器，你需要這樣寫代碼：new Confusing((Object)null)。這可以確保只有Confusing(Object)是可應(yīng)用的。更一般地講，要想強(qiáng)制要求編譯器選擇一個(gè)精確的重載版本，需要將實(shí)際的參數(shù)轉(zhuǎn)型為形式參數(shù)所聲明的類型。
以這種方式來(lái)在多個(gè)重載版本中進(jìn)行選擇是相當(dāng)令人不快的。在你的API中，應(yīng)該確保不會(huì)讓客戶端走這種極端。理想狀態(tài)下，你應(yīng)該避免使用重載：為不同的方法取不同的名稱。當(dāng)然，有時(shí)候這無(wú)法實(shí)現(xiàn)，例如，構(gòu)造器就沒有名稱，因而也就無(wú)法被賦予不同的名稱。然而，你可以通過(guò)將構(gòu)造器設(shè)置為私有的并提供公有的靜態(tài)工廠，以此來(lái)緩解這個(gè)問題[EJ Item 1]。如果構(gòu)造器有許多參數(shù)，你可以用Builder模式[Gamma95]來(lái)減少對(duì)重載版本的需求量。
如果你確實(shí)進(jìn)行了重載，那么請(qǐng)確保所有的重載版本所接受的參數(shù)類型都互不兼容，這樣，任何兩個(gè)重載版本都不會(huì)同時(shí)是可應(yīng)用的。如果做不到這一點(diǎn)，那么就請(qǐng)確保所有可應(yīng)用的重載版本都具有相同的行為[EJ Item 26]。
總之，重載版本的解析可能會(huì)產(chǎn)生混淆。應(yīng)該盡可能地避免重載，如果你必須進(jìn)行重載，那么你必須遵守上述方針，以最小化這種混淆。如果一個(gè)設(shè)計(jì)糟糕的API強(qiáng)制你在不同的重載版本之間進(jìn)行選擇，那么請(qǐng)將實(shí)際的參數(shù)轉(zhuǎn)型為你希望調(diào)用的重載版本的形式參數(shù)所具有的類型。   回復(fù)  更多評(píng)論