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

時間 2020-05-29

標籤談談 java 經常使用設計模式欄目 Java 简体版

原文原文鏈接

背景

最近一口氣看完了Joshua Bloch大神的Effective Java（下文簡稱EJ）。書中以tips的形式羅列了Java開發中的最佳實踐，每一個tip都將其意圖和要點壓縮在了標題裏，這種作法我很喜歡：一來比較親切，比起難啃的系統書，EJ就像是一本Java的《俚語指南》；二來記憶起來十分方便，整本書過一遍就能望標題生義。html

在通讀這本書時，我發現做者屢次列舉現有類庫中的實現的設計模式，我有意將其收集起來，這些實現至關經典，我以爲有必要落成一篇文章。隨着之後對類庫的理解愈來愈深，我也會持續追加上本身發現的Pattern。java

概述

因爲篇幅限制，本主題會作成一個系列，每一個系列介紹3-4個模式。
本文介紹的設計模式（可跳轉）：程序員

建造者
 工廠方法
 享元
 橋接面試

Here We Go

建造者（Builder）

定義：將一個複雜對象的構建與它的表示分離，使得一樣的構建過程能夠建立不一樣的表示。算法

場景：建立複雜對象的算法獨立於該對象的組成部分以及它們的裝配方式時；對象內部結構複雜；對象內部屬性相互依賴。spring

類型：建立型數據庫

建造者模式在Java中最普遍的用途就是複雜對象建立。比起類構造器或Getter/Setter，它同時保證了建立過程的可讀性（和屬性名一致的設參方法）和安全性（未建立完畢的對象不會逸出），同時它還有：參數可選、可在類繼承層次中複用、對集合類字段更加友好等等優勢。對於複雜的對象均可使用建造者模式，代價是必定的性能開銷與編寫工做量，好在後者能夠用Lombok這樣的代碼生成插件來解決。設計模式

藉助Lombok生成類的建造者：api

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<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日誌等等，這體現了橋接當中的獨立變化。