談談Java常用類庫中的設計模式 - Part Ⅰ

d1zzyboy發表於2020-05-19
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 莫屬。這個來自JAVA 8 Function包的函式式介面，將工廠方法模式的編寫成本降到極低。

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 的定義，它是一個泛型，按照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)

相關文章