工程師或多或少都曾經遇過因應服務的擴展,必須要增加輸入參數的情況。
今天接到要做一杯紅茶的需求? 好的沒問題!
建一個方法,只需要輸入茶包、冰塊、甜度三種參數,這樣不僅紅茶,連其他茶飲都可以一併完成。
過幾天接到飲品要有額外添加料的需求? 也沒問題!
在上述方法中增加一個新的參數,這參數會帶入要增加那些添加料的資訊,需求完成。
又過了幾天,飲品要分成大、中、小杯裝…?
飲品要分成店家提供的杯子或顧客自行攜帶的杯子…?
飲品要做成熱飲…?
飲品要出特定季節版本或活動版本…?
飲品要根據店別出特定店版本…?
太多太多的需求慢慢加進來,才會發現…你的參數是不是越來越多了? 從一行變兩行、變三行。如果這個方法來自於介面的話,那代表在更動上會動到更多更多的實做類別。
累不累?
麻不麻煩?
之後老闆說,準備開一間咖啡店,飲品作法與原先的飲料店不同,但至些需求參數相差無幾,頭開始痛了嗎?
你需要的是可以幫你在一個實作類別中抽離建構子(Constructor)與參數的東西。
就是今天要介紹的,在解綁建構子與輸入參數的設計模式 – Builder
Builder Pattern
中文常見名稱 配接器模式、轉接器模式
屬於 Creational Pattern 的一種,目的是為了將建構子與過多的輸入參數解綁,讓建構子單純是建構子,參數的輸入可以根據流程進行動態的處理,而不是所有使用該方法的人都必須要求所有輸入參數的部分。
這樣就算今天需要建立許多的實作方法,每一個實作的方法與參數還是可以分開處理。你可以更彈性化的去加入其他設計模式來幫助完成。
優點:
缺點:
該圖引用來自 Wiki Builder Pattern - Class Diagram
架構圖物件說明
項目 | 說明 |
---|---|
Product | 產品 |
Builder | 介面 |
ConcreteBuilder | 實作 Builder 介面的類別 |
Director | 負責設計 ConcreteBuilder 該如何執行 |
而有時候為求處理上的方便,會把輸入參數的方法改寫為回傳本身,這樣就可以在一行內處理完。如以下:
範例中建立介面 InitBuilder、實作類 InitBuilderImpl,藉由不同的 Director (Director_1、Director_2) 處理輸入參數、執行,取得不同的結果。
總結:
用一句話介紹 Builder Pattern: 解偶建構子或參數的設計模式
Design Pattern