第五十二條、通過接口引用對象

1. 如果有合適的接口類型存在，那么對于參數(shù)、返回值、變量和域來說，就都應(yīng)該使用接口類型的聲明。只有當你利用構(gòu)造器創(chuàng)建某個對象的時候，才真正需要引用這個對象的類。如：List<Subscriber> subscribers = new Vector<Subscriber>();

2. 如果養(yǎng)成了這個習(xí)慣，程序?qū)⒏屿`活。當決定更換實現(xiàn)的時候，只需要改變構(gòu)造器中類的名稱。周圍的代碼都可以正常工作，對于這種變化并不在意。

3. 如果沒有合適的接口存在，完全可以用類而不是接口來引用對象。

   比如：值類（String和BigInteger）。值類很少會用多個實現(xiàn)編寫，通常是final的，并且很少有對應(yīng)的接口。

   第二種情形是：對象屬于一個框架，而框架的基本類型就是類，如果對象屬于這種基于類的框架，就應(yīng)該使用相關(guān)的基類（往往是抽象類）來引用這個對象。

   最后一種情形是：類實現(xiàn)了接口，但是它提供了接口中不存在的額外方法。

第五十三條、接口優(yōu)先于反射機制

1. 核心反射機制（core reflection facility）

   java.lang.reflect提供了“通過程序訪問關(guān)于已裝載的類的信息”的能力。給定一個Class實例，可以獲得Constructor、Method和Field實例，分別代表該Class類所表示的類的Constructor、Method和Field。

   這些對象提供了“通過程序來訪問類的成員名稱、域類型、方法簽名等信息”的能力。

   而且，Constructor、Method、Field實例能夠使你通過反射機制操作它們的底層對等體：通過調(diào)用上述三項上的方法，可以構(gòu)造底層類的實例。調(diào)用底層類的方法，并訪問底層類中的域。

   反射機制reflection允許一個類使用另一個類，即使當前者被編譯時后者還不存在。

2. 反射機制的代價：

   • 喪失了編譯時類型檢查的好處，包括異常檢查。

   • 執(zhí)行反射訪問所需要的代碼非常笨拙和冗長。

   • 性能損失：比普通方法要慢不少。

3. 核心反射機制最初是為了基于組建的應(yīng)用創(chuàng)建工具而設(shè)計的。這類工具需要根據(jù)裝載類，并且用反射功能找出它們支持哪些方法和構(gòu)造器。這些工具允許用戶交互式地構(gòu)造出訪問這些類的應(yīng)用程序，但是所產(chǎn)生出來的這些應(yīng)用程序能夠以正確的方式訪問這些類，而不是以反射的方式。反射只是在設(shè)計的時候被用到。

4. 通常，普通應(yīng)用程序在運行時不應(yīng)該以反射的方式訪問對象。有一些復(fù)雜的應(yīng)用程序需要使用反射機制。比如：類瀏覽器、對象監(jiān)視器、代碼分析工具、解釋型的內(nèi)嵌式系統(tǒng)。在RPC（遠程過程調(diào)用）系統(tǒng)中使用反射機制也是十分合適的。

5. 反射機制的好處：

   對于有些程序，它們必須用到在編譯時無法獲取的類，但是在編譯時存在適當?shù)慕涌诨蛘叱?，通過它們可以引用這個類。以反射方式創(chuàng)建實例，然后通過它們的接口或者超類，正常的方式訪問這些實例。Class.newInstance方法就已經(jīng)提供不帶參數(shù)的構(gòu)造方法。

6. 總結(jié)：反射機制是一種功能強大的機制，對于特定的復(fù)雜系統(tǒng)編程任務(wù)，它是非常必要的，但是它也有一些缺點。如有可能，就應(yīng)該僅僅使用反射機制來實例化對象，而訪問對象時使用編譯時已知的某些接口或者超類。

第五十四條、謹慎地使用本地方法

1. Java Native Interface（JNI）允許Java應(yīng)用調(diào)用本地方法Native Method，本地方法是指用本地程序設(shè)計語言（如C或C++）來編寫特殊的方法。本地方法在本地語言中可以執(zhí)行任意的計算任務(wù)，并返回到Java程序設(shè)計語言。

2. 本地方法的用途：

   • 提供了”訪問特定于平臺的機制“的能力，比如訪問注冊表和文件鎖。

   • 提供了訪問遺留代碼庫的能力，從而可以訪問遺留數(shù)據(jù)。

   • 本地方法可以通過本地語言，編寫應(yīng)用程序中注重性能的部分，以提高系統(tǒng)的性能。

3. 使用本地方法來提高性能的方法不值得提倡：

   隨著JVM實現(xiàn)變得越來越快。使用本地方法的缺點在于：由于本地語言不是安全的，會引發(fā)內(nèi)存毀壞的錯誤；由于本地語言是與平臺相關(guān)的，使用本地方法的應(yīng)用程序不再是可自由移植的；使用本地方法的程序也更加難以調(diào)試。在進入和退出本地方法的時候需要相關(guān)固定的開銷；膠合代碼難以閱讀。

第五十五條、謹慎地進行優(yōu)化

1. 三條關(guān)于優(yōu)化的格言：

   • 很多計算上的過失都被歸咎于效率（沒有必要達到的效率）。而不是任何其他的原因——甚至包括盲目地做傻事。
   • 不要去計較效率上的一些小小得失，在97%的情況下，不成熟的優(yōu)化才是一切問題的根源。
   • 在優(yōu)化方面，我們應(yīng)該遵守兩條規(guī)則：
     • 不要進行優(yōu)化，
     • 還是不要進行優(yōu)化。

2. 優(yōu)化的弊大于利，尤其是不成熟的優(yōu)化。這并不意味著，在完成程序之前就可以忽略性能問題，必須要在設(shè)計過程中考慮性能問題：努力避免那些限制性能的設(shè)計決策；要考慮API設(shè)計決策的性能后果。一旦謹慎地設(shè)計了程序，并且產(chǎn)生了一個清晰、簡明、結(jié)構(gòu)良好的實現(xiàn)，那么就到了考慮優(yōu)化的時候了。

第五十六條、遵守普遍接受的命名慣例

1. java平臺建立了一整套很好的命名慣例naming convention，不嚴格地說，這些命名慣例分為兩大類：字面的（typographical）和語法的（grammatical）。

2. 字面的慣例簡要的介紹：

   • 包的名稱應(yīng)該是層次狀的，用句號分割每個部分。每個部分都包括小寫字母和數(shù)字（很少），任何將在你的組織之外使用的包，其名稱都應(yīng)該以你的組織的Internet域名開頭，并且頂級域名放在前面，例如：edu.cmu,com.sun,gov.nsa。標準類庫和一些可選的包，其名稱以java和javax開頭，這屬于這一規(guī)則的例外。用戶創(chuàng)建的包的名稱絕對不能以java和javax開頭；

   • 包名稱的剩余部分應(yīng)該包括一個或者多個描述該包的組成部分。這些描述應(yīng)該比較簡短，一般不超過8個字符，鼓勵使用有意義的縮寫：如util，awt等。

   • 類和接口的名稱，包括枚舉和注解類型的名稱，都應(yīng)該包括一個或者多個單詞，每個單詞的首字母大寫（如Timer和TimerTask）；應(yīng)該盡量避免縮寫。

   • 方法和域的名稱與類和接口的名稱一樣，遵循相同的字面慣例，只是第一個字母應(yīng)該小寫。如果首字母縮寫組成的單詞是一個方法或者域名稱的第一個單詞，它就應(yīng)該是小寫形式。

   • ”常量域“它的名稱應(yīng)該包含一個或者多個大寫的單詞，中間用下劃線符號隔開。

   • 局部變量名稱的字面慣例與成員名稱類似，只不過它也允許縮寫，單個字符和短字符序列的意義取決于上下文。

   • 參數(shù)類型名稱通常由單個字母組成：通常是下面五種類型之一：T表示任意的類型；E表示集合的元素類型；K和V表示映射的鍵和值類型；X表示異常。任何類型的序列都可以是T、U、V或者T1、T2、T3。

3. 語法命名慣例：比字面慣例更加靈活但是有爭議。

   • 類通常用一個名詞或者名詞短語命名；

   • 接口的命名與類類似，或者用一個已-able或者-ible結(jié)尾的形容詞來命名：Runable，Iterable等

   • 執(zhí)行某個動作的方法通常用動詞或者動詞短語來命名，對于返回boolean值的方法，其名稱往往以單詞”is“開頭，后面跟名詞或者名詞短語，或者任何具有形容詞功能的單詞或者短語：isEmpty，isEnabled等

   • 如果方法返回被調(diào)用對象的一個非boolean的函數(shù)或者屬性，通常使用名詞、名詞短語或者以動詞”get“開頭的動詞短語來命名：如size,hasCode或者getTime。

   • 轉(zhuǎn)換對象類型的方法、返回不同類型的獨立對象的方法，通常稱為toType;

   • 返回視圖的方法通常稱為asType:asList

   • 返回一個與被調(diào)用的對象同值的基本類型方法，通常被稱為typeValue:intValue;

   • 靜態(tài)工廠的常用名稱為：valueOf、of、getInstance、newInstance、getType和newType。