《Effective Java》是 Java 領域的經典之作，其影響力不亞於《Think in Java》。它是每個 Java 開發者的必讀書籍，值得多次閱讀品味，並不斷實踐其中的經驗技巧。
兩年前讀過此書，當時自身技術水平並不算高，對於其中的原則不求甚解。現在重溫以前的筆記，加上這兩年的程式設計經驗，竟然有種豁然開朗的感覺。 「書讀百遍，其義自見。」古人說得有道理啊。
這裡簡單介紹幾條開發中經常用到的技巧，比如 Builder、物件方法、介面定義等。
1. 存在多個構造引數時，考慮使用構建器（Builder）
這裡講的就是構建者模式，使用 Builder 給物件設定構造引數，從而去除重疊的構造方法。
在第三方庫中，比如 OkHttp、Retrofit，經常見到這樣的設計。我們用 Builder 設定引數，然後呼叫 build 方法構造物件，程式碼看起來非常清爽，沒有多餘的構造引數，使用起來也方便。
如果類的構造方法中有多個引數，而且引數可選，Builder 模式是不錯的選擇。
2. 使用私有構造器或者列舉型別強化 Singleton 屬性
單例模式推薦使用靜態內部類，保證執行緒安全的同時，延遲物件的初始化。列舉的話，不是很推薦。
3. 避免建立不必要的物件
建立物件是有開銷的，對於不可變的（可以理解為無狀態的）物件，可以始終被重用。善於使用快取（cache）是好的習慣，我們要做一個環保的程式設計師。比如 Android Message 裡面的物件池，就是一種優化策略。
優先使用基本資料型別而不是裝箱資料型別，因為基本型別佔用更少的記憶體空間，對於移動端來說，記憶體優化是一個永恆的話題。
4. 覆蓋 equals 時總要覆蓋 hashCode，始終覆蓋 toString
對於一般的 Java Bean 物件，我都會重寫其 toString 方法， 這樣在列印日誌的時候，就能看見它的內部資料，這點非常有用。
對於需要作為 HashMap 的鍵的物件，一定要重寫 hashCode 和 equals 方法，這樣有利於雜湊表均勻分佈，提升查詢的效能。 另外，兩個物件 equals 相等，hashCode 必須相等；hashCode 相等，equals不一定相等。這個很好理解，equals 保證 HashMap 鍵的唯一性；hashCode 相等表示兩個物件放在 HashMap 陣列的同一個位置上。
提示：現在的 IDE 實在是太傻瓜式了，可以一鍵生成 toString, equals 和 hashCode 方法，這時候有什麼理由不重寫呢。
5. 介面優於抽象類
介面本質上是一種規範，用來定義通用的規則，然後各個功能提供者進行不同的實現。這裡，我想到了一條軟體設計原則--介面隔離，是說一個介面只用來定義一種規範，每個介面都是獨立的，不能讓一個介面有多個定義。
骨架實現，AbstractXXX，為抽象類提供了實現上的幫助，又不強加抽象類定義型別的限制。比如 Java 裡面的 AbstractList，是列表類的抽象實現，其子類有 ArrayList 和 LinkedList 等。
6. 優先考慮靜態成員類
靜態成員類不持有外部類的引用，所以不會造成記憶體洩漏問題，主要是用來輔助外部類。還有匿名內部類，比如直接建立的 Runnable，建議內部保持簡短，大約 10 行或者更少些，否則影響程式的可讀性。
7. 列表優先於陣列
列表和陣列的不同點：
- 陣列是可變的，泛型是不可變的。
- 陣列是具體化的，泛型通過擦除來實現的。
陣列提供了執行時的型別安全，但是沒有編譯時的型別安全。列表裡面有許多實用的方法，而陣列就沒有提供哦。建議優先使用集合型別 List，而不是陣列型別 E[]。
8. 使用列舉代替 int 常量
列舉型別是例項受控的，它們是單例的泛化，本質上是單元素的列舉。列舉的優點是易讀性好，更加安全，功能強大。但是與 int 型別相比，列舉有些效能缺點：裝載和初始化列舉時會有時間和空間的成本。在 Android 端，通常不建議使用。
9. for-each 迴圈優先於傳統的 for 迴圈
for-each 迴圈在簡潔性和預防 bug 方面優於傳統的 for 迴圈，而且沒有效能損失，應該儘可能地使用 for-each。
這一點深有感觸，IDE 通常會提示使用 for-each，畢竟簡潔就是美啊。
10. 如果需要精確的答案，請避免使用 float 和 double
float 和 double 並沒有提供完全精確的結果，所以不應該用於需要精確計算的場合，尤其是貨幣計算。如果想要系統記錄十進位制小數點，可以使用 BigDecimal。
float 型別確實是個坑，經常會出現計算不準確的問題，一般推薦使用雙精度浮點型 double。
以上就是從《Effective Java》裡面摘錄的十條程式設計建議，還有好多幹貨呢，趕快去閱讀吧～