第47條:了解和使用類庫

Top 100 Java Libraries on Github 2016

Library Number of Projects Type % of projects
junit.junit 2412 Testing 62.45% Total Projects Tested 3,862
org.slf4j.slf4j-api 895 Logging 23.17% Unique Repos Used 12,059
com.google.guava.guava 650 Utilities 16.83% Total Records 47,251
log4j.log4j 615 Logging 15.92% Avg. repos per project 12.23
commons-io.commons-io 537 Utilities 13.90%
org.slf4j.slf4j-log4j12 479 Logging 12.40%
org.mockito.mockito-all 394 Mocks 10.20%
commons-lang.commons-lang 369 Utilities 9.55%
ch.qos.logback.logback-classic 342 Logging 8.86%
org.apache.commons.commons-lang3 327 Utilities 8.47%
javax.servlet.servlet-api 323 Java Extension 8.36%
org.apache.httpcomponents.httpclient 295 Web 7.64%
org.springframework.spring-context 290 Utilities 7.51%
com.fasterxml.jackson.core.jackson-databind 277 Parsing 7.17%
commons-codec.commons-codec 260 Utilities 6.73%
org.mockito.mockito-core 260 Mocks 6.73%
org.springframework.spring-test 259 Testing 6.71%
joda-time.joda-time 248 Utilities 6.42%
com.google.code.gson.gson 246 Parsing 6.37%
org.testng.testng 234 Testing 6.06%

第48條:如果需要精確的答案，請避免使用float和double

float和double類型主要是為了科學計算和工程計算而設計的。它們執行二進制浮點運算( binary floating-point arithmetic )，這是為了在廣泛的數值范圍上提供較為精確的快速近似計算而精心設計的。然而，它們并沒有提供完全精確的結果，所以不應該被用于需要精確結果的場合。float和double類型尤其不適合用于貨幣計井，因為要讓一個float或者double精確地表示0.1(或者10的任何其他負數次方值)是不可能的。

遺憾的是，它輸出的結果是$0.61000000000000000001.

總而言之，對于任何需要精確答案的計算任務，請不要使用float或者double。如果你想讓系統來記錄十進制小數點，并且不介意因為不使用基本類型而帶來的不便，就請使用BigDecimal。使用BigDecima!還有一些額外的好處，它允許你完全控制舍人，每當一個操作涉及舍入的時候，它允許你從8種舍入模式中選擇其一。如果你正通過法定要求的舍入行為進行業務計算，使用Bigpecimal是非常方便的。如果性能非常關鍵，并且你又不介意自己記錄十進制小數點，而且所涉及的數值又不太大，就可以使用int或者long。如果數值范圍沒有超過9位{進制數字，就可以使用int;如果不超過18位數字，就可以使用long。如果數值可能超過18位數字，就必須使用BigDecimal.

第49條:基本類型優先于裝箱基本類型

這個程序運行起來比預計的要慢一些，因為它不小心將一個局部變量(sum)聲明為是裝箱基本類型Long, 而不是基本類型long. 程序編譯起來沒有錯誤或者警告，變量被反復地裝箱和拆箱，導致明顯的性能下降。

那么什么時候應該使用裝箱基本類型呢?它們有幾個合理的用處。第一個是作為集合中的元素、鍵和值。你不能將基本類型放在集合中，因此必須使用裝箱基本類型。這是一種更通用的特例。在參數化類型中，必須使用裝箱基本類型作為類型參數，因為Java不允許使用基本類型。例如，你不能將變量聲明為ThreadLocal類型，因此，必須使用ThreadLocal代替。最后，在進行反射的方法調用(見第53條)時，必須使用裝箱基本類型。

第50條:如果其他類型更適合,則盡量避免使用字符串

經常被錯誤地用字符串來代替的類型包括基本類型、枚舉類型和聚集類型。

• 宇符串不適合代替其他的值類型。

• 字符串不適合代替枚舉類型。

• 字符串不適合代替聚集類型。
  如果一個實體有多個組件，用一個字符串來表示這個實體通常是很不恰當的。例如，下面這行代碼來自于真實的系統—標識符的名稱已經被修改了，以免發生糾紛:
  

這種方法有許多缺點。如果用來分隔域的字符也出現在某個域中，結果就會出現混亂。為
了訪問單獨的域，必須解析該字符串，這個過程非常慢，也很繁瑣，還容易出錯。你無法提供equals, toString或者compareTo方法，只好被迫接受String提供的行為。更好的做法是，簡單地編寫一個類來描述這個數據集，通常是一個私有的靜態成員類(見第22條).

第53條:接口優先千反射機制

核心“反封機制(core reflection facility) java.lang.reflect, 提供了“通過程序來訪問關于已裝載的類的信息”的能力。給定一個CIass實例，你可以獲得Constructor, Method和Field實例，分別代表了該Class實例所表示的類的Constructor(構造器)、Method(方法)和Field(域)。這些對象提供了“通過程序來訪問類的成員名稱、域類型、方法簽名等信息”的能力。

而且，Constructor, Method和Field實例使你能夠通過反扮機制操作它們的底層對等體:通過調用Constructor, Method和Field實例上的方法，可以構造底層類的實例、調用底層類的方法，并訪問底層類中的域。例如，Method.invoke使你可以調用任何類的任何對象上的任何方法(遵從常規的安全限制)。反射機制(reflection)允許一個類使用另一個類，即使當前者被編譯的時候后者還根本不存在。然而，這種能力也要付出代價:

• 喪失了編譯時類型檢查的好處
  包括異常檢查。如果程序企圖用反射方式調用不存在的或者不可訪問的方法，在運行時它將會失敗，除非采取了特別的預防措施.
• 執行反射訪問所需要的代碼非常笨拙和冗長
  編寫這樣的代碼非常乏味，閱讀起來也很困難。
• 性能損失
  反射方法調用比普通方法調用慢了許多。具體慢了多少，這很難說，因為受到了多個因素的影響。在我的機器上，速度的差異可能小到2倍，也可能大到50倍。

有一些復雜的應用程序需要使用反射機制。這些示例中包括類瀏覽器、對象監視器、代碼分析工具、解釋型的內嵌式系統。在RPC(遠程過程調用)系統中使用反射機制也是非常合適的。

第54條:謹慎地使用本地方法

Java Native Interface (JNI)允許Java應用程序可以調用本地方法( native method ) ,所謂本地方法是指用本地程序設計語言(比如C或者C++)來編寫的特殊方法。本地方法在本地語言中可以執行任意的計算任務，并返回到Java程序設計語言。

從歷史上看，本地方法主要有三種用途。它們提供了“訪問特定于平臺的機制”的能力，比如訪問注冊表(registry)和文件鎖(file lock）。它們還提供了訪問遺留代碼庫的能力，從而可以訪問遺留數據(legacy data)。最后，本地方法可以通過本地語言，編寫應用程序中注重性能的部分，以提高系統的性能。

使用本地方法來提高性能的做法不值得提倡
使用本地方法有一些嚴重的缺點口因為本地語言不是安全的，所以，使用本地方法的應用程序也不再能免受內存毀壞錯誤的影響。因為本地語言是與平臺相關的，使用本地方法的應用程序也不再是可自由移植的。使用本地方法的應用程序也更難調試。在進入和退出本地代碼時，需要相關的固定開銷，所以，如果本地代碼只是做少量的工作，本地方法就可能降低(decrease)性能。最后一點，需要“膠合代碼”的本地方法編寫起來單調乏味，并且難以閱讀。

第56條:遵守普遍接受的命名慣例

對于首字母縮寫。到底應該全部大寫還是只有首字母大寫，沒有統一的說法。雖然大寫更常見一些，但還是強烈建議采用僅有首字母大寫的形式:即使連續出現多個首字母縮寫的形式，你仍然可以區分出一個單詞的起始處和結束處。
下面這兩個類名你更愿意看到哪一個，HTTPURL還是HttpUrl ?

類型參數名稱通常由單個字母組成。這個字母通常是以下五種類型之一:T表示任意的類型，E表示集合的元素類型，K和V表示映射的鍵和值類型，X表示異常。任何類型的序列可以是T, U, V或者T1, T2, T3.

對于返回boolean值的方法。其名稱往往以單詞“is”開頭，很少用has。

轉載于:https://www.cnblogs.com/myitroad/p/7614710.html

《新程序員》：云原生和全面數字化實踐50位技術專家共同創作，文字、視頻、音頻交互閱讀

總結

以上是生活随笔為你收集整理的《Effective Java》第8章 通用程序设计的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。