>>>  技術話題—商業文明的嶄新時代  >>>

簡體     傳統

2005.11.29 李建忠

Builder模式的緣起

假設創建游戲中的一個房屋House設施，該房屋的構建由幾個部分組成，且各個部分要富于變化。

如果使用最直觀的設計方法，每一個房屋部分的變化，都將導致房屋構建的重新修正……

動機（Motivation）

在軟件系統中，有時候面臨著“一個復雜對象”的創建工作，其通常由各個部分的子對象用一定的算法構成；由于需求的變化，這個復雜對象的各個部分經常面臨著劇烈的變化，但是將它們組合在一起的算法卻相對穩定。

如何應對這種變化？如何提供一種“封裝機制”來隔離出“復雜對象的各個部分”的變化，從而保持系統中的“穩定構建算法”不隨著需求改變而改變？

意圖（Intent）

將一個復雜對象的構建與其表示相分離，使得同樣的構建過程可以創建不同的表示。

——《設計模式》GoF

結構（Structure）

協作（Collaborations）

游戲框架中的Builder應用

系統接口部分Builder

Builder不需要關心具體的門是什么樣子的，墻是什么樣子的，它只是定義了軸線的東西。

系統相對穩定的部分Director

系統相對變化的部分ConcreteBuilder

Client

Director和抽象類Builder是綁定的比較緊的，但是在它里面，沒有任何具體ConcreteBuilder的任何信息。也就是說，Director不會被具體依賴所改變，當ConcreteBuilder改變時，Director不用變。

另外，客戶端需要new一個ConcreteBuilder，當ConcreteBuilder改變時，這個程序還是需要改變Client。這里我們可以用一種動態的機制回避這種改變。我們可以從一個配置文件里面讀取ConcreteBuilder具體類的名字，和程序集的名字，然后通過動態反射，讓客戶程序不發生任何依賴的改變。

這樣，當ConcreteBuilder需要改變的時候，只需要新增一個Builder的子類，修改一下配置文件就可以了。

這是非常符合開放封閉原則的，對擴展開放，對更改關閉。

這也符合依賴倒置原則。房屋的構建過程是一個高層抽象，房屋的具體實現細節依賴于高層抽象。高層抽象比較穩定，底層實現細節比較多變。

Builder模式的幾個要點

Builder模式主要用于“分步驟構建一個復雜的對象”。在這其中“分步驟”是一個穩定的算法（即Director，如上面例子中的GameManager），而復雜對象的各個部分（即ConcreteBuilder）則經常變化。

變化點在哪里，封裝哪里——Builder模式主要在于應對“復雜對象各個部分”的頻繁需求變動。其缺點在于難以應對“分步驟構建算法”的需求變動。（例如房屋構造如果經常改變，那么這個Builder模式也沒有意義了）

AbstractFactory模式解決“系列對象”的需求變化，Builder模式解決“對象部分”的需求變化。Builder模式通常和Composite模式組合使用。

.NET框架中的Builder應用

在ASP.Net中，我們在寫一個Page類時，這個類繼承自System.Web.UI.Page。Page其實就是一個Builder，它是一個容器。它有很多方法，就是所謂的BuilderPart()方法，例如：OnInit()、OnLoad()、OnPreRender()、Render()等，它們都是虛方法，我們都可以去重寫，提供我們自己的實現。當我們編譯到bin文件夾下的dll時，我們就生成了一個我們自己的ConcreteBuilder實例。實際上系統使用的是Page基類。

2010.9.24

MSDN 網絡廣播 李建忠 2013-08-22 08:43:01