背景
最近一口氣看完了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=https://www.cnblogs.com/notayeser/p/"package-summary.html">functional interface
* whose functional method is {@link #get()}.
*
* @param the type of results supplied by this supplier
*
* @since 1.8
*/
@FunctionalInterface
public interface Supplier {
/**
* 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)
轉載請註明出處，本文鏈接：https://www.uj5u.com/ruanti/8570.html
標籤：設計模式