看《重構（注釋版）》中“封裝集合（Encapsulate Collection）”一節時，由于該重構手法對于不同的 Java 版本會有相對應不同的處理方式，于是注釋者在旁邊給出提示：Java 2 中的新 Collections API 主要是由《Java 解惑》、《Effective Java》這兩本書的作者開發改進的。我想，這可真是一個大消息，Java 類庫的開發者所寫的書一定得看，開發者肯定深入探尋過 Java 內部機制，說不定能從書中獲得未知的知識點呢。
好在我記得自己電腦里下載過《Java 解惑（中文版）》的清晰電子版，于是改變路線，看起這本書來了。真是不看不知道，一看嚇一跳！里面有 95 個 Java 謎題，一點點地看了之后，我是既慚愧又興奮，因為里面的題真的是“莫名其妙”，直白點就是：十有八九是想都想不出來的，⊙﹏⊙b…想要真正掌握 Java ，我覺得《Java 解惑》是不得不看的。大多謎題可謂是前所未見的炸彈，一不小心就 over 了。
快點切入正題，如文章標題所示，我從《Java 解惑》中似乎認識到了幾個名詞，之所以用似乎修飾，因為重載、重寫、隱藏這幾個接觸過了，而遮蔽、遮掩或許是見過但也就忘光了。就整理一下文中的一些與此相關的 Java 謎題用自己的理解描述一下吧。
重載（overload）：同一個類中名字相同但參數列表不同的多個方法之間的關系。
關于重載，是我們比較熟悉的了，最常見的就是運用在類的多個構造函數中，看一下 Java 幫助文檔，就可以明白這一情況了。而在《Java 解惑》中，作者給出了下面一個謎題：
- 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);
- }
- }
問此時 main() 中將會輸出什么？初初一看，并沒有多分析就覺得應該是輸出“Object”，雖然Java中的數組實際上也是引用類型，但畢竟Object 是所有類的最終父類，而且目前 JDK 就連參數中的基本數據類型變量也可以被自動想上轉型成包裝類而成為 Object 的子類。于是我保守一點地就認為參數 null 應該是匹配到 Object 那個重載方法去了。
可是這答案是錯的，JVM 對于重載方法的解析是這樣的：先找出方法名匹配的所有可能的方法；然后根據傳進來的形參再次篩選出可能的重載方法；最后才是在這些方法中匹配到一個最精確的一個方法。于是，上面的那個謎題就變成確定哪一個才是最精確這一點子上了。
而關于如何判斷最精確，有這樣的機制：如果某個重載方法能夠接收所有傳遞給另一個重載方法的實參類型，那么對于參數列表來看，顯然后者至少是前者的子集，當然也就更精確了。
回到謎題上來，Confusing(Object)可以接受任何傳遞給 Confusing(double[ ])的參數（任何數組引用最終能夠都是 Object 對象），因此 main() 中的 null 應該是被 JVM 匹配到 Confusing(double[ ]) 中，也就有了與我所認為的結果相反的輸出了。
小結：這個謎題表明了我們在寫重載方法時，最好是明確地區分出各個方法中的參數列表，不要讓彼此之間有互相包含、模糊不清的關系。雖然重載是為了在相同名字的方法中傳入實參，由 JVM 動態解析選擇合適的方法，但有時也很容易陷入這種方便背后所帶來的地雷區當中。其中一種可行的辦法就是，提供不同的方法名。但是構造函數的名字一定得相同的啊？
實際上，在《重構與模式》第六章中，作者用他自身的項目經驗對“創建”這一話題展開了講解，就算是構造函數，也有很好的重構手法將其清晰地區分開來，不使用重載而是用不同名稱的方法，將原本需要重載的構造函數委托給具有最大完整參數列表的私有構造函數中。又是一本經典，值得看哦…
重寫（override）：父類中的實例方法被其子類重新實現。既然是實例方法，那就是非 static 修飾的了，否則就是 static 靜態方法了，那叫做類方法。在我看來，正是重寫這一機制的存在，才為多態機制提供了基礎。或許 implements （實現）一個 interface （接口）中所聲明的方法也能成為重寫，因為 interface 的一部分存在原因也是為了多態。
對于重寫，在《Java 解惑》中有下面這個謎題讓我明白：絕對不能在構造函數中調用可能會被子類重寫的方法。
- class Point {
- protected final int x, y;
- private final String name;
-
- Point(int x, int y) {
- this.x = x;
- this.y = y;
- name = makeName();
- }
-
- protected String makeName() {
- return "[" + x + "," + y + "]";
- }
-
- public final String toString() {
- return name;
- }
- }
-
- public class ColorPoint extends Point {
- private final String color;
-
- ColorPoint(int x, int y, String color) {
- super(x, y);
- this.color = color;
- }
-
- protected String makeName() {
- return super.makeName() + ":" + color;
- }
-
- public static void main(String[] args) {
- System.out.println(new ColorPoint(4, 2, "purple"));
- }
- }
此時程序運行結果并不是我們所想的 [4,2]:purple ，而是 [4,2]:null 。為什么會這樣？看看下面用流程標號注釋過的代碼，就能理解了。
- class Point {
- protected final int x, y;
- private final String name;
-
- Point(int x, int y) {
- this.x = x;
- this.y = y;
- name = makeName();// 3. 由于被子類重寫過的makeName()
- }
-
- protected String makeName() {
- return "[" + x + "," + y + "]";
- }
-
- public final String toString() {
- return name;
- }
- }
-
- public class ColorPoint extends Point {
- private final String color;
-
- ColorPoint(int x, int y, String color) {
- super(x, y); // 2. 調用Point父類構造函數
- this.color = color; // 5. 初始化 color ，可是已經太晚了...
- }
-
- protected String makeName() {
- // 4. 問題來了：它在子類構造函數之前調用了
- // 而此時的 color 是 null 的啊！！！
- return super.makeName() + ":" + color;
- }
-
- public static void main(String[] args) {
- // 1. 調用ColorPoint子類構造函數
- System.out.println(new ColorPoint(4, 2, "purple"));
- }
- }
思路很清晰了，ColorPoint 子類中的構造函數中的 this.color = color; 還未被執行到就將 null 作為 String color 的值了。正是因為這種來來回回的調用使得程序變得不正常了，在我看來，有那么一點類似于“回調”的意思。
要去除這種代碼結構的不合理，最好還是把 Point 父類構造函數中調用 makeName() 方法一句去掉，然后在 toString 中判斷并調用 makeName() 來為 name 初始化，如下：
小結：重寫對于多態固然重要，但是設計出不正確的代碼結構的話，原本想要的多態就會被扭曲甚至造成反效果。于是，絕對不要在構造函數中調用可能會被子類重寫的方法。
好像文字太多的文章看了容易使人暈乎乎的，啰啰嗦嗦、模模糊糊地才寫了兩個詞兒，還是分開來寫吧。其實，看了一部分《Java 解惑》才明白還有好多好多 Java 里面該注意的要點。要想在適當的時候辨清各種語法上、機制上的知識點，難啊！
記得高中語文課上讀過一片抒情的散文，標題為“哦——香雪！”而我看了《Java 解惑》，想說“噢——Java！”~~~~(>_<)~~~~
總結：
1、在我們編程領域，好書真的是一大把，就看自己有沒時間、有沒策略地去吸收了；
2、有時候看好書時留意作者對其他書籍的“友情鏈接”，或者出版社推薦的相關書籍，這樣就能夠免去自己慢慢搜尋好書的過程了，O(∩_∩)O哈！
本文出自 “螞蟻” 博客，請務必保留此出處http://haolloyin.blog.51cto.com/1177454/372691