1. 程式人生 > >java中的設計模式-Builder模式

java中的設計模式-Builder模式

Builder 模式的目的?

抽離複雜物件的建構函式,讓我們可以通過多種方法的排列組合構建複雜的物件。如果構造器引數過多,可以考慮 builder 模式
這樣說也有點抽象,舉個例子吧。

舉個例子

比如 非常熱門的訊息佇列RabbitMQAMQP.BasicProperties

因為它的屬性比較多,所以建構函式也是挺嚇人的。

我看到也不太想呼叫。
如果現在要構造一條訊息

  • 投遞模式(delivery mode)為 2
  • 優先順序(priority)是 2
  • content-type 為 text/plain

在沒有 builder 模式之前,是這樣構造的

new AMQP.BasicProperties("text/plain",null,null,2,1,null,null,null,null,null,null,null,null,null);

痛苦啊!!!不信,你自己也可以嘗試構造一下。

  • 建構函式有很多你不想設定的引數
  • 你要看準,哪個引數要賦值,哪個引數不賦值,一不小心就可能出錯了。而這裡有 14 個引數。。。
  • 維護性差,寫完程式碼再看一下,也看不出這個引數究竟是什麼意思。還要點進去,一個一個引數地看才知道是什麼意思

而用了 Builder 模式後。

new AMQP.BasicProperties.Builder()
    .contentType("text/plain")
    .deliveryMode(2)
    .priority(1)
    .build();

舒暢!!!

Builder 是如何實現?

很簡單。

  • BasicProperties中新增一個叫Builder的內部類
  • Builder 中所有欄位和BasicProperties類是完全一致的
  • Builder例項在呼叫build函式的時候,再呼叫BasicProperties的建構函式構造物件。

程式碼如下

public static class BasicProperties{
    private String contentType;
    private String contentEncoding;
    private Map<String,Object> headers;
    private Integer deliveryMode;
    private Integer priority;
    //... 還有很多屬性

    public BasicProperties(
        String contentType,
        String contentEncoding,
        Map<String,Object> headers,
        Integer deliveryMode,
        //...
        String clusterId){
            this.contentType = contentTypel;
            this.contentEncoding = contentEncoding;
            //...
    }

    public static final class Builder {
        private String contentEncoding;
        private Map<String,Object> headers;
        private Integer deliveryMode;
        private Integer priority;
        //.. 和BasicProperties的欄位一致的。
        
        public Builder contentType(String contentType){
            this.contentType = contentType; 
            return this; 
        }
    
        public Builder contentEncoding(String contentEncoding){
            this.contentEncoding = contentEncoding; 
            return this; 
        }
        
        public BasicProperties build() {
            return new BasicProperties
                ( contentType
                  contentEncoding,
                  //還有很多屬性
                );
        }
    }
}

分析

Builder 模式的好處

  • 不用花太多心思去記構造器的順序,在 ide 中輸入一個點就有自動提示了
  • 好維護,很容易看到看明白這是什麼屬性

壞處

  • 構造物件就要先呼叫 Buidler 構造器,多了構造器的開銷
  • 類的關係變得複雜了

其他的做法

如果不用 Builder 模式,有其他的做法嗎?

重疊構造器?

比如,上面的例子,我構造的訊息只需 投遞模式(delivery mode)、優先順序(priority)、 content-type ,專門為這幾個引數弄個專門的建構函式,可以嗎?
呼叫就變成這樣了。

new AMQP.BasicProperties("text/plain",2,1)

可以,

  • 但依然不太好看。
  • 如果有不同的需求,各種屬性都排列組合一下也麻煩。
  • 不實際,因為類欄位的型別可能會是一樣的,有些組合註定不行

javaBean 模式呢?

BasicProperties  p = new AMQP.BasicProperties();
p.setContentType("text/plain");
p.setDeliveryMode(2);
p.setPriority(1);

在《effective java》中就探討過這個可能,書中是這樣說的

因為構造過程被分到幾個呼叫中,在構造過程中 javaBean 可能處於不一致的狀態。類無法僅僅通過檢驗構造器引數的有效性來保證一致性。試圖使用處於不一致狀態的物件,將導致失敗,這種失敗與包含錯誤的程式碼大相徑庭,因此它除錯起來十分困難。與此相關的另一點不足在於,javaBeans 模式阻止了把類做成不可變的可能,這需要程式設計師付出格外的努力來確保它的執行緒安全。

這話就有點摸不著頭腦,什麼意思。讀了幾次也有點懵。

其實意思是大概的,

  1. javaBean 是構造與欄位賦值分離的,有可能 執行緒 1 在給物件 Obj 賦值,還沒有賦完成的時候,執行緒 2 就拿了 Obj 的值了,就不一致了
  2. 如果 Obj 的欄位全都是 final 的,不會出現上面那種情況,但欄位只能會通過建構函式賦值(builder 模式也行),不能使用 javaBeans 的 setXXX 函式賦值了。
  3. 所以有多執行緒要求的,比如是傳給訊息佇列的物件,程式設計師要保證下執行緒安全。
  4. 這是一個開放開閉的問題,Javabean 這樣的寫法確實和完全開放沒啥區別,如果欄位確定下來不用改了就最好設為 final 。

以上