背景 最近一口氣看完了Joshua Bloch大神的 Effective Java （下文簡稱EJ）。書中以tips的形式羅列了Java開發中的最佳實踐，每個tip都將其意圖和要點壓縮在了標題里，這種做法我很喜歡：一來比較親切，比起難啃的系統書，EJ就像是一本Java的《俚語指南》；二來記憶起來十分 ...
背景
最近一口氣看完了Joshua Bloch大神的Effective Java（下文簡稱EJ）。書中以tips的形式羅列了Java開發中的最佳實踐，每個tip都將其意圖和要點壓縮在了標題里，這種做法我很喜歡：一來比較親切，比起難啃的系統書，EJ就像是一本Java的《俚語指南》；二來記憶起來十分方便，整本書過一遍就能望標題生義。
在通讀這本書時，我發現作者多次列舉現有類庫中的實現的設計模式，我有意將其收集起來，這些實現相當經典，我覺得有必要落成一篇文章。隨著以後對類庫的理解越來越深，我也會持續追加上自己發現的Pattern。
概述
由於篇幅限制，本主題會做成一個系列，每個系列介紹3-4個模式。
本文介紹的設計模式（可跳轉）：
Here We Go
建造者 （Builder）
定義：將一個複雜對象的構建與它的表示分離，使得同樣的構建過程可以創建不同的表示。
場景：創建複雜對象的演算法獨立於該對象的組成部分以及它們的裝配方式時；對象內部結構複雜；對象內部屬性相互依賴。
類型：創建型
建造者模式在Java中最廣泛的用途就是複雜對象創建。比起類構造器或Getter/Setter，它同時保證了創建過程的可讀性（和屬性名一致的設參方法）和安全性（未創建完畢的對象不會逸出），同時它還有：參數可選、可在類繼承層次中復用、對集合類欄位更加友好等等優點 。對於複雜的對象都可使用建造者模式，代價是一定的性能開銷與編寫工作量，好在後者可以用Lombok這樣的代碼生成插件來解決。
藉助Lombok生成類的建造者：
import lombok.*;
@Data
@Builder
@NoArgsConstructor
@AllArgsConstructor(access = AccessLevel.PRIVATE)
public class Foo {
private String name;
private Integer height;
private Integer length;
public static void main(String[] args) {
Foo f = Foo.builder().name("SQUARE").height(10),length(10).build();
}
}
除了使用建造者創建普通Java Bean之外，許多類庫中配置類對象也照葫蘆畫瓢。比如SpringBoot中對Swagger2的簡單配置，使其在生產環境下關閉。
@Configuration
public class SwaggerConfig {
@Value("${spring.profiles.active}")
private String prop;
@Bean
public Docket api() {
return new Docket(DocumentationType.SWAGGER_2)
.enable(!prop.contains("prod"))
.select()
.apis(RequestHandlerSelectors.any()).build();
}
}
工廠方法 （Factory Method）
定義：定義一個創建對象的介面，讓子類決定實例化哪一個類。工廠方法使一個類的實例化延遲到其子類。
場景：明確計劃不同條件下創建不同實例時。
類型：創建型
若要找工廠方法在JAVA原生類庫中最貼切的對照物，非 Supplier
package java.util.function;
/**
* Represents a supplier of results.
*
* <p>There is no requirement that a new or distinct result be returned each
* time the supplier is invoked.
*
* <p>This is a <a href="package-summary.html">functional interface</a>
* whose functional method is {@link #get()}.
*
* @param <T> the type of results supplied by this supplier
*
* @since 1.8
*/
@FunctionalInterface
public interface Supplier<T> {
/**
* Gets a result.
*
* @return a result
*/
T get();
}
如果將工廠類作為方法入參，將保證對象會在最迫切的時機才會創建：
public class StreamTest {
public static void main(String[] args) {
Stream.generate(()->{
System.out.println("creating a new object.");
return new Object();
}).limit(3);
}
}
==============================
輸出:
Stream.generate(Supplier<T> s)創建了一個流，並聲明瞭這個流的元素來源：一個由Lambda表達式編寫的工廠。編譯器將其推導為一個Supplier實例。在對象創建時將列印日誌，然而結果表明沒有任何對象創建成功。因為在未聲明終結函數時，賦予Stream的任何中間函數都不會執行。
使用工廠方法，生產數據的時機將由消費者把握，這是一種懶漢思想。
再回到 Supplier<T> 的定義，它是一個泛型，按照EJ的建議，當使用泛型作為方法入參和返回值時，最好遵循 PECS 規則。
Producer-Extends Consumer-Super
Supplier通常是放在方法入參的生產者，所以應該這麼聲明：
public void generate(Supplier<T extends Shape> supplier) {}
這樣Shape的所有子類工廠都能傳入到此方法中，增強其拓展性。對應了工廠方法定義當中 讓子類決定實例化哪一個類 的部分。
享元 (Flyweight)
定義：運用共用技術有效地支持大量細粒度的對象。
場景：應用使用大量對象，造成龐大的存儲開銷；對象中的大多數狀態可以移至外部，剩下的部分可以共用。
類型：結構型
JDK類庫中使用了大量的靜態工廠（泛指創建對象的靜態類/靜態方法），這些靜態工廠有一個重要的作用：為重覆的調用返回相同的對象。使類成為實例受控的類（instance-controlled），這實際上就是享元的思想。
舉個例子，下麵是 Boolean.valueOf(boolean b) 的代碼片段。
/**
* The {@code Boolean} object corresponding to the primitive
* value {@code true}.
*/
public static final Boolean TRUE = new Boolean(true);
/**
* The {@code Boolean} object corresponding to the primitive
* value {@code false}.
*/
public static final Boolean FALSE = new Boolean(false);
public static Boolean valueOf(boolean b) {
return (b ? TRUE : FALSE);
}
Boolean 作為布爾類型的包裝類，進行了實例控制。 因為布爾類型的值只有 True 和 False ，除此之外沒有其他狀態欄位，所以類庫設計者選擇在類載入時初始化兩個不可變實例，在靜態工廠中不創建對象。
這也表明 Boolean.valueOf 返回的實例在執行==和equals時結果一致。
其他包裝類型如Byte，Short，Integer也有類似的設計：使用名為XCache（X表示類型名）的私有內部類中存儲值在 -128 ~ 127 之間共256個實例，併在靜態工廠中使用。在面試中經常碰見的數值包裝類“==”問題，考點就在這裡。
橋接（Bridge）
定義：將抽象部分與他的實現部分分離，使它們都可以獨立地變化。
場景：實現系統可能有多個角度分類，每一種角度都可能變化；在構件的抽象化和具體化之間增加更多的靈活性，避免兩個層次之間的靜態繼承關係；控制系統中繼承層次過多過深。
類型：結構型
首先瞭解一個概念：服務提供者框架（Service Provider Framework）（下文簡稱SPF）。
服務提供者框架指這樣一個系統：多個服務提供者實現一個服務，系統為服務提供者的客戶端提供多個實現，並把它們從多個實現中解耦出來。
它由4種組件組成：服務介面：需被實現的介面或抽象類
提供者註冊API：實現類用來註冊自己到SPF中的
服務訪問API：客戶端用來獲取實現的
服務提供者介面：實現類的工廠對象，用來創建實現類的實例，是可選的
SPF模式的應用是如此廣泛，其實現的變體也有很多。如Java 6提供的標準實現ServiceLoader，還有Spring、Guice這樣的依賴註入框架。但我選擇舉一個大家更為熟悉的例子：JDBC。
使用JDBC與資料庫交互是每個Java程式員的必經之路，而它的設計實際上也是SPF模式：
服務介面 -> Connection
提供者註冊API：DriverManager.registerDriver
服務訪問API：DriverManager.getConnection
服務提供者介面：Driver
想要使用不同的資料庫連接實現，只需通過服務訪問API切換即可。這體現了橋接中將抽象與實現分離的精神。
（實際上如果載入多個資料庫驅動，DriverManager會逐個嘗試連接，並返回連接成功的實例。並不能人為選擇提供者，但可以通過更改提供者註冊代碼來實現。）
Druid、Hikari等現代連接池的實現往往比JDBC定義的服務介面更加豐富，如監控、插件鏈、SQL日誌等等，這體現了橋接當中的獨立變化。
參考：
[1] Play With Java ServiceLoader And Forget About Dependency Injection Frameworks - (2016/10/02)
https://dzone.com/articles/play-with-java-serviceloader-forget-about-dependen
[2] Effective Java - 機械工業出版社 - Joshua Bloch (2017/11)
[3] 《大話設計模式》 - 清華大學出版社 - 陳傑 (2007/12)
