java中的設計模式-Builder模式
阿新 • • 發佈:2018-12-21
Builder 模式的目的?
抽離複雜物件的建構函式,讓我們可以通過多種方法的排列組合構建複雜的物件。如果構造器引數過多,可以考慮 builder 模式
這樣說也有點抽象,舉個例子吧。
舉個例子
比如 非常熱門的訊息佇列RabbitMQ 的 AMQP.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 模式阻止了把類做成不可變的可能,這需要程式設計師付出格外的努力來確保它的執行緒安全。
這話就有點摸不著頭腦,什麼意思。讀了幾次也有點懵。
其實意思是大概的,
- javaBean 是構造與欄位賦值分離的,有可能 執行緒 1 在給物件 Obj 賦值,還沒有賦完成的時候,執行緒 2 就拿了 Obj 的值了,就不一致了
- 如果 Obj 的欄位全都是 final 的,不會出現上面那種情況,但欄位只能會通過建構函式賦值(builder 模式也行),不能使用 javaBeans 的 setXXX 函式賦值了。
- 所以有多執行緒要求的,比如是傳給訊息佇列的物件,程式設計師要保證下執行緒安全。
- 這是一個開放開閉的問題,Javabean 這樣的寫法確實和完全開放沒啥區別,如果欄位確定下來不用改了就最好設為 final 。
以上