優秀代碼的必知必會（二）？

1.在公共類中使用訪問方法而不是直接訪問屬性

這種設計不是優秀的設計方式。若是屬性直接暴露出去，若是須要修改返回值，那基本是不可能的，由於調用方散佈在不少地方。若是是提供的訪問方法，咱們只須要改方法自己便可。

2.最小化可變性，能用不可變對象最好用不可變對象

不可變對象的優勢：
不可變對象是線程安全的。
不可變對象能夠被自由地共享。
不可變對象也能夠共享內部屬性。
不可變對象能夠被重複使用。
不可變對象提供了免費的原子失敗機制。

3.該選擇接口仍是抽象類

在 Java 中，經過 接口 和 抽象類 來容許多個實現。在 Java 8 中也引入了接口的默認方法實現，因此這兩種機制都容許爲某些實例方法提供實現。因爲 Java 中只容許單一繼承，經常使用的方式是接口定義了類型，可能提供了一些默認的方法，抽象類去實現多個接口並實現通用接口方法，具體的實現類去繼承抽象類並實現抽象類中的抽象方法。

4.該選擇組合仍是繼承

繼承是實現代碼重用的有效方式，但並不老是最好的工具。與方法調用不一樣，繼承打破了封裝，一個子類依賴於其父類的實現細節來保證其正確的功能。若是父類發生了變化，即便子類並無作任何的改動也會致使子類被破壞。

不要繼承一個現有的類，而應該給你的新類增長一個私有屬性，該屬性是現有類的實例引用，這種設計被稱爲組合。如今不依賴於現有類的實現細節，即便將新的方法添加到現有的類中，也不會對新類產生影響。

繼承是強大的，也能夠最大化代碼重用，只有在子類和父類之間存在真正的子類型關係時才適用。 若是子類與父類不在同一個包中，而且父類不是爲繼承而設計的，那就可使用組合來代替繼承。

5.接口最好只用來定義類型

接口不包含任何方法，它只包含靜態 final 屬性，每一個輸出一個常量，這樣的接口叫常量接口，這是對接口的糟糕使用方式。

若是常量跟類的關係密切，那麼咱們能夠把常量定義在類中。假如是公共的常量，咱們應該用枚舉類型來定義它們。

接口只能用於定義類型，它們不該該僅用於定義常量。

6.優先考慮使用泛型

一個集合對象中數據類型應該是一致的，若是不規定數據的具體類型，在編譯期是沒有任何問題的。但到程序運行時，若是類型不一致，就與可能拋出 ClassCastException 異常。所以，咱們須要使用泛型強制約束數據的類型，讓問題暴露在編譯期，而不是在運行期。

7.使用限定通配符來增長 API 的靈活性

咱們用泛型強制規定了參數的類型，所以它很是的不靈活，使用場景很是少。相對於提供的不可變的類型，有時須要比此更多的靈活性咱們就須要使用通配符類型。

因此將類型從 List 更改成 List<? extends T>。在 API 中使用通配符類型，雖然棘手，但使得 API 更加靈活。 若是編寫一個將被普遍使用的類庫，請使用通配符類型來最大化該 API 的靈活性。

8.當心泛型和可變參數的結合使用

由於可變參數和泛型不能很友好的限制，泛型可變參數不是類型安全的，但它們是合法的。若是選擇使用泛型可變參數編寫方法，請首先確保該方法類型一致，而後使用 @SafeVarargs 註解對其進行標註，以避免形成使用不愉快。

9.不要爲類打標籤，而應使用類層次結構

一個類用 枚舉聲明，標籤屬性和 switch 語句來判斷類型，會使代碼可讀性更差，容易出錯的，並且效率低下。所以，帶標籤的類很應少最好別用。當遇到一個帶有標籤屬性的現有類時，能夠考慮將其重構爲一個類層次中。

10.注意消除非檢查警告

未經檢查的警告是重要的，不要忽視他們。由於每一個未經檢查的警告表明在運行時出現 ClassCastException 異常的可能性，儘可能消除這些警告。若是沒法消除未經檢查的警告，而且能夠證實引起該警告的代碼是安全類型的，則能夠在儘量小的範圍內使用 @SuppressWarnings(「unchecked」) 註解來禁止警告。 並註釋爲何是安全的。

11.該選擇列表仍是數組

數組和泛型具備很是不一樣的類型規則。 數組是協變和具體化的， 泛型是不變和類型擦除的。

所以，數組能保證運行時類型的安全性，但不保證編譯時類型的安全性，反之亦然。

通常來講，數組和泛型不能很好地混合工做。若是你發現把它們混合在一塊兒，獲得編譯時錯誤或者警告，首先應該使用列表來替換數組。

12.使用枚舉類型替代整型常量

枚舉的優勢：
提供了編譯時類型的安全性，可使用 == 運算符來比較不一樣枚舉類型的值。
具備相同名稱常量的枚舉類型能夠和平共存，由於每種類型都有其本身的名稱空間。
還容許添加任意方法和屬性並實現任意接口，功能更強大。

枚舉更具可讀性，更安全，更強大。

13.始終使用 Override 註解

此註解只能在方法聲明上使用，它代表帶此註解的方法聲明重寫了父類的聲明。若是始終使用這個註解，它將避免產生大量的惡意 bug。

若是在每一個方法聲明中使用 Override 註解，而且認爲要重寫父類聲明，那麼編譯器能夠保護免受不少錯誤的影響。

14.優先使用標準的函數式接口

java.util.function 包提供了大量標準函數式接口供你使用。 若是其中一個標準函數式接口完成這項工做，則一般應該優先使用它，而不是專門構建的函數式接口。 這將使你的 API 更容易學習，經過減小其沒必要要概念，並將提供重要的互操做性好處，由於許多標準函數式接口提供了有用的默認方法。

不要提供具備多個重載的方法，這些重載在相同的參數位置上使用不一樣的函數式接口，若是這樣作可能會在調用方中產生歧義。

15.Stream

在 Java 8 中添加了 Stream API，以簡化順序或並行執行批量操做的任務。

流 (Stream)，表示有限或無限的數據元素序列。
流管道 (stream pipeline)，表示對這些元素的多級計算。

Stream 中的元素能夠來自任何地方。常見的源包括集合，數組，文件，正則表達式模式匹配器，僞隨機數生成器和其餘流。

流能夠很容易地作一些事情：
統一轉換元素序列。
過濾元素序列。
使用單個操做組合元素序列。
將元素序列累積到一個集合中，可能經過一些公共屬性將它們分組。
在元素序列中搜索知足某些條件的元素。
遍歷元素序列。

Stream 類提供了不少好用又簡單的方法，能夠多加使用。

PS:
清山綠水始於塵，博學多識貴於勤。
我有酒，你有故事嗎？
微信公衆號：「清塵閒聊」。
歡迎一塊兒談天說地，聊代碼。