設計模式 --建造者模式

正號先生發表於2020-08-19
設計模式

前言

我們都知道設計模式分為建立型，結構型和行為型。建立型有，單例模式，工廠模式，建造者模式和原型模式。

今天，我們再來學習另外一個比較常用的建立型設計模式，Builder 模式，中文翻譯為建造者模式或者構建者模式，也有人叫它生成器模式。

很多部落格總結的關於建造者模式的作用是：建立複雜物件的時候，用建造者模式可以使客戶端不必知道產品內部組成的細節。 這雖然是一個很重要的特徵，但是還有一個特徵以及作用很多人都並不知道。我們接下來就來好好的探討一番。

建造者模式的作用

在平時的開發中，建立一個物件最常用的方式是，使用 new 關鍵字呼叫類的建構函式來完成。雖然這是最簡單最常用的，但是我們仔細想一想真的是所有場景都適用嗎？

場景分析

  有如下的一個場景：
  有一個工廠類，這個工廠類有如下幾個成員變數：
      1. 工廠名字
      2. 工廠員工列表
      3. 工廠裝置列表

要想讓這個工廠正常的執行，這3個成員變數必須被正確賦值。那麼此時，我們最常見的方法就是在構造方法中實現這些成員變數的賦值。

當成員變數不多的時候，像上訴說的3個，這樣並沒有什麼問題，但是當成員變數變成6個，12個甚至更多，那繼續沿用現在的設計思路，建構函式的引數列表會變得很長，程式碼在可讀性和易用性上都會變差。在使用建構函式的時候，我們就容易搞錯各引數的順序，傳遞進錯誤的引數值，導致非常隱蔽的 bug。

解決辦法

解決這個問題的辦法你應該也已經想到了，那就是用 set() 函式來給成員變數賦值，以替代冗長的建構函式。我們將必填的成員變數，放在我們的構造方法中，強制建立類物件的時候就要填寫。將其他不是必填的成員變數我們通過 set() 函式來設定，讓使用者自主選擇填寫或者不填寫。

這樣程式碼在可讀性和易用性上提高了很多。

引入構造模式

當我們的如下幾個需求的時候，上訴使用set()函式的設計思路可能就不太滿足了

  1. 我們剛剛說的，將必填的成員變數放到構造方法。如果必填項很多，那構造方法又會出現我們之前說的那個問題。但是，如果我們把必填項也通過 set() 方法設定，那校驗這些必填項是否已經填寫的邏輯就無處安放了。
  2. 除此之外，假設配置項之間有一定的依賴關係，比如，如果使用者設定了員工列表， 就必須顯式地設定員工工資；或者配置項之間有一定的約束條件，比如，員工和工資必須一一對應。如果我們繼續使用現在的設計思路，那這些配置項之間的依賴關係或者約束條件的校驗邏輯就無處安放了。
  3. 如果我們希望這個工廠類物件某些屬性如name是不可變的，也就是說，物件在建立好之後，就不能再修改這些內部的屬性值。要實現這個功能，我們就不能在外部暴露 set() 方法。

為了解決這些問題，建造者模式就派上用場了。

使用建造者來實現我們的需求

我們可以把校驗邏輯放置到 Builder 類中，先建立建造者，並且通過 set() 方法設定建造者的變數值，然後在使用 build() 方法真正建立物件之前，做集中的校驗，校驗通過之後才會建立物件。除此之外，我們把 Factory 的建構函式改為 private 私有許可權。這樣我們就只能通過建造者來建立 Factory 類物件。並且，Factory 沒有為不可變屬性提供任何 set() 方法，這樣我們建立出來的物件就做到了相對不可。程式碼如下：


public class Factory {
  private String factoryName;  //工廠名字
  private List<Integer> employeeIds; //員工列表
  private Map<Integer,Integer> salaryMap; //員工工資
  private List<String> equipmentName; //裝置列表

  //私有構造方法
  private Factory(){}
  private Factory(Builder builder) {
    this.factoryName = builder.factoryName;
    this.employeeIds = builder.employeeIds;
    this.salaryMap = builder.salaryMap;
    this.equipmentName = builder.equipmentName;
  }
  //...省略getter方法...

  //我們將Builder類設計成了Factory的內部類。
  //我們也可以將Builder類設計成獨立的非內部類FactoryBuilder。
  public static class Builder {
    private String factoryName;  
    private List<Integer> employeeIds; 
    private Map<Integer,Integer> salaryMap; 
    private List<String> equipmentName; 

    public Factory build() {
      // 校驗邏輯放到這裡來做，包括必填項校驗、依賴關係校驗、約束條件校驗等
      if (StringUtils.isBlank(factoryName)) {
        throw new IllegalArgumentException("...");
      }
      
      for(Integer employeeId : employeeIds){
        if (salaryMap.get(employeeId) == null) {
            throw new IllegalArgumentException("...");
        }
      }
      return new ResourcePoolConfig(this);
    }

    public Builder setFactoryName(String factoryName) {
      if (StringUtils.isBlank(factoryName)) {
        throw new IllegalArgumentException("...");
      }
      this.factoryName = factoryName;
      return this;
    }

    public Builder setEmployeeIds(List<Integer> employeeIds) {
      // 員工不能為0
      if (employeeIds.size() == 0) {
        throw new IllegalArgumentException("...");
      }
      this.employeeIds = employeeIds;
      return this;
    }

    public Builder setSalaryMap(Map<Integer,Integer> salaryMap) {
      if (salaryMap.size() == 0) {
        throw new IllegalArgumentException("...");
      }
      this.salaryMap = salaryMap;
      return this;
    }

    public Builder setEquipmentName(List<String> equipmentName) {
      // 裝置必須大於兩個
      if (equipmentName.siez() < 2) {
        throw new IllegalArgumentException("...");
      }
      this.minIdle = minIdle;
      return this;
    }
  }
}

// 這段程式碼會丟擲IllegalArgumentException，因為裝置只有一臺
List<Integer> employeeIds =  Collections.singletonList(1);
Map<Integer, Integer> salaryMap = Collections.singletonMap(1, 9000);
List<String> equipmentName =  Collections.singletonList("新型裝置");
Factory factory = new Factory.Builder()
        .setFactoryName("萬能工廠")
        .setEmployeeIds(employeeIds)
        .setSalaryMap(salaryMap)
        .setEquipmentName(equipmentName)
        .build();

總結

我們來與工廠模式做一個對比，建造者模式是讓建造者類來負責物件的建立工作。工廠模式，是由工廠類來負責物件建立的工作。

那它們之間有什麼區別呢？實際上，工廠模式是用來建立不同但是相關型別的物件（繼承同一父類或者介面的一組子類），由給定的引數來決定建立哪種型別的物件。

建造者模式是用來建立一種型別的複雜物件，通過設定不同的可選引數，“定製化”地建立不同的物件。網上有一個經典的例子很好地解釋了兩者的區別。

顧客走進一家餐館點餐，我們利用工廠模式，根據使用者不同的選擇，來製作不同的食物，比如披薩、漢堡、沙拉。對於披薩來說，使用者又有各種配料可以定製，比如乳酪、蕃茄、起司，我們通過建造者模式根據使用者選擇的不同配料來製作披薩。

實際上，我們也不要太學院派，非得把工廠模式、建造者模式分得那麼清楚，我們需要知道的是，每個模式為什麼這麼設計，能解決什麼問題。只有瞭解了這些最本質的東西，我們才能不生搬硬套，才能靈活應用，甚至可以混用各種模式創造出新的模式，來解決特定場景的問題。

相關文章