設計模式-建立型-生成器模式（BUILDER）

咱們先看看gof對生成器模式的結構描述。

　　值得注意的是跟工廠方法模式同樣的，生成器模式也引入了一個新的抽象，不過這個抽象的名字是builder。咱們能夠在這個結果上補全出工程方法模式的結構（以下圖）。正如圖書所示，用client替代Director，增長一個product抽象類，去掉ConcreteBuilder中的getResult方法，這就是一個典型的工廠方法模式的結構圖。須要注意一點的是builder模式與工廠方法模式除了在這點相似其餘的地方沒有任何相似的地方。我增長這個圖的目的不是爲了讓讀者困惑而是想表達模式與模式之間比較容易混淆，在學習一個模式的時候要注意追尋一個模式的根本需求而不是浮於一些例子的表面。至於怎麼作？筆者的經驗，把gof的書讀上n遍，一些東西就天然開朗了。固然能筆者的博客能幫到你那就更好了。^_^

　　咱們繼續來討論生成器模式。在gof的書中對於生成器模式是這樣描述的。

　　「將一個複雜對象的構建與它的表示分離，使得一樣的構建過程能夠建立不一樣的表示。」

　　咱們使用書中的例子來舉例。

　　

　　關於生成者模式的定義首先吸引咱們的是該對象是複雜對象，構建這個複雜對象可能須要不少步驟。那麼什麼是複雜對象的構建與它的表示呢？ 就上面的結構圖，筆者的理解是ASCIIText，TeXText，TextWidget這三個對象就是定義中所說的複雜對象。複雜對象的構建是什麼呢？這裏分兩類，一類是複雜對象的構建步驟一類是複雜對象的構建實現。構建實現被封裝在了ASCIIConverter，TeXConverter，TextWidgetConverter中。構造步驟則封裝了RTFReader中，很明顯這裏的Converter就是builder角色，RTFReader就是director角色。他們一塊兒構成了複雜對象的構建。那麼什麼事複雜對象的表示呢？ASCIIText，TeXText，TextWidget這三個對象是咱們要的結果，對結果的表示在builder角色中有一個成員方法GetResult。全部複雜對象的獲取最後是經過builder類的成員函數的來獲取的，這個成員函數自己就是對目的複雜對象的表示。因而咱們能夠預期像下面同樣的客戶代碼。

　　void getComplexObj()

　　{

　　　　RTFReader objReader;

　　　　objReader.setTextConvert(new ASCIIConverter());

　　　　objReader.setTextConvert(new TeXConverter());

　　　　objReader.setTextConvert(new TextWidgetConverter());

　　　　Text * result;

　　　　for each converter in objReader

　　　　{

　　　　　　objReader.ParseRTF();

　　　　　　result = objReader.getTextConvert()->getResult();

　　　　　　//...  operation about the complex object

　　　　}

　　}

固然筆者代碼是不徹底的，筆者想說明的也僅僅是一樣的構建方法是如何能有不一樣的表示的。正如gof書中所說的那樣生成器模式的重點在於一步一步構建出你想要的複雜對象，固然中間不可缺乏的是幾個角色分別是：1.Director，它負責了指導對象如何一步一步被建立的。2.Builder它負責了建立對象的細節實現和保存對象的狀態.3，最爲重要的是客戶不是從director獲取這個複雜對象而是從Builder中獲取，這樣構建於表示分離了。這就是builder設計模式存在的目的。