什麼是建造者模式

發現很多框架的原始碼使用了建造者模式，看了一下覺得挺實用的，就寫篇文章學習一下，順便分享給大家。

建造者模式是什麼呢？用一句話概括就是建造者模式的目的是為了分離物件的屬性與建立過程，是的，只要記住並理解紅字的幾個部分，建造者模式你就懂了。

為什麼需要建造者模式

建造者模式是構造方法的一種替代方案，為什麼需要建造者模式，我們可以想，假設有一個物件裡面有20個屬性：

• 屬性1
• 屬性2
• ...
• 屬性20

對開發者來說這不是瘋了，也就是說我要去使用這個物件，我得去了解每個屬性的含義，然後在建構函式或者Setter中一個一個去指定。更加複雜的場景是，這些屬性之間是有關聯的，比如屬性1=A，那麼屬性2只能等於B/C/D，這樣對於開發者來說更是增加了學習成本，開源產品這樣的一個物件相信不會有太多開發者去使用。

為了解決以上的痛點，建造者模式應運而生，物件中屬性多，但是通常重要的只有幾個，因此建造者模式會讓開發者指定一些比較重要的屬性或者讓開發者指定某幾個物件型別，然後讓建造者去實現複雜的構建物件的過程，這就是物件的屬性與建立分離。這樣對於開發者而言隱藏了複雜的物件構建細節，降低了學習成本，同時提升了程式碼的可複用性。

雖然感覺基本說清楚了，但還是有點理論，具體往下看一下例子。

建造者模式程式碼示例

舉一個實際場景的例子：

大家知道一輛車是很複雜的，有發動機、變速器、輪胎、擋風玻璃、雨刮器、氣缸、方向盤等等無數的部件。

使用者買車的時候不可能一個一個去指定我要那種型別的變速器、我要一個多大的輪胎、我需要長寬高多少的車，這是不現實的

通常使用者只會和銷售談我需要什麼什麼樣的型別的車，馬力要不要強勁、空間是否寬敞，這樣銷售就會根據使用者的需要去推薦一款具體的車

這就是一個典型建造者的場景：車是複雜物件，銷售是建造者。我告訴建造者我需要什麼，建造者根據我的需求給我一個具體的物件

根據這個例子，我們定義一個簡單的汽車物件：

 1 public class Car {
 2 
 3     // 尺寸
 4     private String size;
 5     
 6     // 方向盤
 7     private String steeringWheel;
 8     
 9     // 底座
10     private String pedestal;
11     
12     // 輪胎
13     private String wheel;
14     
15     // 排量
16     private String displacement;
17     
18     // 最大速度
19     private String maxSpeed;
20 
21     public String getSize() {
22         return size;
23     }
24 
25     public void setSize(String size) {
26         this.size = size;
27     }
28 
29     public String getSteeringWheel() {
30         return steeringWheel;
31     }
32 
33     public void setSteeringWheel(String steeringWheel) {
34         this.steeringWheel = steeringWheel;
35     }
36 
37     public String getPedestal() {
38         return pedestal;
39     }
40 
41     public void setPedestal(String pedestal) {
42         this.pedestal = pedestal;
43     }
44 
45     public String getWheel() {
46         return wheel;
47     }
48 
49     public void setWheel(String wheel) {
50         this.wheel = wheel;
51     }
52 
53     public String getDisplacement() {
54         return displacement;
55     }
56 
57     public void setDisplacement(String displacement) {
58         this.displacement = displacement;
59     }
60 
61     public String getMaxSpeed() {
62         return maxSpeed;
63     }
64 
65     public void setMaxSpeed(String maxSpeed) {
66         this.maxSpeed = maxSpeed;
67     }
68 
69     @Override
70     public String toString() {
71         return "Car [size=" + size + ", steeringWheel=" + steeringWheel + ", pedestal=" + pedestal + ", wheel=" + wheel
72             + ", displacement=" + displacement + ", maxSpeed=" + maxSpeed + "]";
73     }
74     
75 }

這裡簡單定義幾個引數，然後建造者物件應運而生：

public class CarBuilder {

    // 車型
    private String type;
    
    // 動力
    private String power;
    
    // 舒適性
    private String comfort;
    
    public Car build() {
        Assert.assertNotNull(type);
        Assert.assertNotNull(power);
        Assert.assertNotNull(comfort);
        
        return new Car(this);
    }

    public String getType() {
        return type;
    }

    public CarBuilder type(String type) {
        this.type = type;
        return this;
    }

    public String getPower() {
        return power;
    }

    public CarBuilder power(String power) {
        this.power = power;
        return this;
    }

    public String getComfort() {
        return comfort;
    }

    public CarBuilder comfort(String comfort) {
        this.comfort = comfort;
        return this;
    }

    @Override
    public String toString() {
        return "CarBuilder [type=" + type + ", power=" + power + ", comfort=" + comfort + "]";
    }

}

說是建造者，其實也不合適，它只是一箇中間物件，用於接收來自外部的資訊，比如需要什麼樣的車型，需要什麼樣的動力啊這些。

然後大家一定注意到了build方法，這個是建造者模式好像約定俗成的方法名，代表建造，裡面把自身物件傳給Car，這個構造方法的實現我在第一段程式碼裡面是沒有貼的，這段程式碼的實現為：

public Car(CarBuilder builder) {
    if ("緊湊型車".equals(builder.getType())) {
        this.size = "大小--緊湊型車";
    } else if ("中型車".equals(builder.getType())) {
        this.size = "大小--中型車";
    } else {
        this.size = "大小--其他";
    }
        
    if ("很舒適".equals(builder.getComfort())) {
        this.steeringWheel = "方向盤--很舒適";
        this.pedestal = "底座--很舒適";
    } else if ("一般舒適".equals(builder.getComfort())) {
        this.steeringWheel = "方向盤--一般舒適";
        this.pedestal = "底座--一般舒適";
    } else {
        this.steeringWheel = "方向盤--其他";
        this.pedestal = "底座--其他";
    }
       
    if ("動力強勁".equals(builder.getPower())) {
        this.displacement = "排量--動力強勁";
        this.maxSpeed = "最大速度--動力強勁";
        this.steeringWheel = "輪胎--動力強勁";
    } else if ("動力一般".equals(builder.getPower())) {
        this.displacement = "排量--動力一般";
        this.maxSpeed = "最大速度--動力一般";
        this.steeringWheel = "輪胎--動力一般";
    } else {
        this.displacement = "排量--其他";
        this.maxSpeed = "最大速度--其他";
        this.steeringWheel = "輪胎--其他";
    }
}

這是真實構建物件的地方，無論多複雜的邏輯都在這裡實現而不需要暴露給開發者，還是那句核心的話：實現了物件的屬性與構建的分離。

這樣用起來就很簡單了：

@Test
public void test() {
    Car car = new CarBuilder().comfort("很舒適").power("動力一般").type("緊湊型車").build();
        
    System.out.println(JSON.toJSONString(car));
}

只需要指定我需要什麼什麼型別的車，然後具體的每個引數自然根據我的需求列出來了，不需要知道每個細節，我也能得到我需要的東西。

建造者模式在開源框架中的應用

文章的開頭有說很多開源框架使用了建造者模式，典型的有Guava的Cache、ImmutableMap，不過感覺MyBatis更為大家熟知，且MyBatis內部大量使用了建造者模式，我們可以一起來看一下。

以原生的MyBatis（即不使用Spring框架進行整合）為例，通常使用MyBatis我們會用以下幾句程式碼：

// MyBatis配置檔案路徑
String resources = "mybatis_config.xml";
// 獲取一個輸入流
Reader reader = Resources.getResourceAsReader(resources);
// 獲取SqlSessionFactory
SqlSessionFactory sqlSessionFactory = new SqlSessionFactoryBuilder().build(reader);
// 開啟一個會話
SqlSession sqlSession = sqlSessionFactory.openSession();
// 具體操作
...

關鍵我們看就是這個SqlSessionFactoryBuilder，它的原始碼核心方法實現為：

public class SqlSessionFactoryBuilder {

  ...

  public SqlSessionFactory build(Reader reader, String environment, Properties properties) {
    try {
      XMLConfigBuilder parser = new XMLConfigBuilder(reader, environment, properties);
      return build(parser.parse());
    } catch (Exception e) {
      throw ExceptionFactory.wrapException("Error building SqlSession.", e);
    } finally {
      ErrorContext.instance().reset();
      try {
        reader.close();
      } catch (IOException e) {
        // Intentionally ignore. Prefer previous error.
      }
    }
  }

  ...

  public SqlSessionFactory build(InputStream inputStream, String environment, Properties properties) {
    try {
      XMLConfigBuilder parser = new XMLConfigBuilder(inputStream, environment, properties);
      return build(parser.parse());
    } catch (Exception e) {
      throw ExceptionFactory.wrapException("Error building SqlSession.", e);
    } finally {
      ErrorContext.instance().reset();
      try {
        inputStream.close();
      } catch (IOException e) {
        // Intentionally ignore. Prefer previous error.
      }
    }
  }
    
  ...

}

因為MyBatis內部是很複雜的，核心類Configuration屬性多到爆炸，比如拿資料庫連線池來說好了，有POOLED、UNPOOLED、JNDI三種，然後POOLED裡面呢又有各種超時時間、連線池數量的設定，這一個一個都要讓開發者去設定那簡直要命了。因此MyBatis在SqlSessionFactory這一層使用了Builder模式，對開發者隱藏了XML檔案解析細節，Configuration內部每個屬性賦值細節，開發者只需要指定一些必要的引數（比如資料庫地址、使用者名稱密碼之類的），就可以直接使用MyBatis了，至於可選引數，配置了就拿開發者配置的，沒有配置就預設來一套。

通過這樣一種方式，開發者接入MyBatis的成本被降到了最低，這麼一種程式設計方式非常值得大家學習，尤其是自己需要寫一些框架的時候。

同樣的大家可以看一下Environment，Environment也使用了建造者模式，但是Environment使用建造者模式最大的作用是讓使用者無法在執行時修改任何環境屬性保證了安全與穩定性，同樣這也是建造者模式的一種經典實現。

建造者模式的類關係圖

其實，建造者模式不像一些設計模式有比較固定或者比較類似的實現方式，它的核心只是分離物件屬性與建立，整個實現比較自由，我們可以看到我自己寫的造車的例子和SqlSessionFactoryBuilder就明顯不是一種實現方式。

看了一些框架原始碼總結起來，建造者模式的實現大致有兩種寫法：

這是一種在Builder裡面直接new物件的方式，MyBatis的SqlSessionFactoryBuilder就是這種寫法，適用於屬性之間關聯不多且大量屬性都有預設值的場景。

另外一種就是間接new的方式了：

我的程式碼示例，還有例如Guava的Cache都是這種寫法，適用於屬性之間有一定關聯性的場景，例如車的長寬高與軸距都屬於車型一類、排量與馬力都與效能相關，可以把某幾個屬性歸類，然後讓開發者指定大類即可。

總體而言，兩種沒有太大的優劣之分，在合適的場景下選擇合適的寫法就好了。

建造者模式的優點及適用場景

建造者模式這種設計模式，優缺點比較明顯。從優點來說：

• 客戶端不比知道產品內部細節，將產品本身與產品建立過程解耦，使得相同的建立過程可以建立不同的產品物件
• 可以更加精細地控制產品的建立過程，將複雜物件分門別類抽出不同的類別來，使得開發者可以更加方便地得到想要的產品

想了想，說缺點，建造者模式說不上缺點，只能說這種設計模式的使用比較受限：

• 產品屬性之間差異很大且屬性沒有預設值可以指定，這種情況是沒法使用建造者模式的，我們可以試想，一個物件20個屬性，彼此之間毫無關聯且每個都需要手動指定，那麼很顯然，即使使用了建造者模式也是毫無作用

總的來說，在IT這個行業，複雜的需求、複雜的業務邏輯層出不窮，這必然導致複雜的業務物件的增加，建造者模式是非常有用武之地的。合理分析場景，在合適的場景下使用建造者模式，一定會使得你的程式碼漂亮得多。

&n