建造者模式：將乙個複雜物件的構建與它的表示分離，使得同樣的構建過程可以建立不同的表示。這是建造者模式的標準表達，不過看著讓人迷惑，什麼叫構建和表示的分離？乙個物件使用建構函式構造之後不就固定了，只有通過它方法來改變它的屬性嗎？而且還要同樣的構建過程搞出不同的表示，怎麼可能呢？多寫幾個建構函式？
其實多寫幾個建構函式，根據不同引數設定物件不同的屬性，也可以達到這樣的效果，只是這樣就非常麻煩了，每次要增加一種表示就要新增乙個建構函式，將來建構函式會多得連自己都不記得了，這違背了開放-封閉的原則。
要不就只能設計幾個set函式，每次屬性不一樣了，我就構造乙個物件，然後用set函式改變物件的屬性。這樣也可以達到效果。只是**就會非常冗餘了，每個要用到這個物件的地方，都要寫上好幾句語句，一旦物件有點什麼變化，還得到處都改一遍，這樣就很容易出錯，以後別人看著這種神邏輯和神**估計也會崩潰了。而且這也違背了依賴倒轉的原則。
於是大神們就開始想了，不能加很多建構函式，也不能直接用一堆set函式，然後發現，有些物件的構建是固定的幾個步驟的，就像一條流水線一樣，任何的產品都是通過每乙個固定的步驟拼湊出來的。例如說一部手機，先放主機板，再放螢幕，再放電池，再放外殼，貼個膜就能賣幾千了，每次推出新產品，就換個更好的主機板，換個大點的螢幕，再整個大容量電池，貼個超牛b的高透膜，又能賣出個新價錢。就是說，這些步驟都沒有變，變的只是每個部分的東西。
這就是大神的厲害之處了，透過現象看本質，基本有變的，有不變的，那敢情好，物件導向的乙個重要指導思想就是，封裝隔離變化的，留出不變的。於是他們就用乙個builder類把步驟中的每個部分封裝起來，這個類的主要作用就是生產每個部件，再抽象一下提公升高度，這樣就依賴倒轉了，這樣每次只需要新增乙個類，這個類還是這幾個部分，只是內部的實現已經不一樣了，這樣就滿足了開放-封閉的原則了。但還是有乙個問題，光有builder類還不行，雖然產品的每個部分都有對應的函式，但是用起來的話，還是跟前面說的set函式一樣，一用就要使用一大堆函式，也就是這變的東西是封裝起來了，但這不變的東西還沒留出來。這時，就新增乙個director類，這個類就是專門規定組裝產品的步驟的，這樣只要告訴director使用哪個builder，就能生產出不同的產品，對於客戶端來說，只看到用了director的乙個construct函式，甚是方便。
再反過來看建造者模式的定義，構建指的就是生產乙個產品的步驟，表示就是每個產品部分的具體實現，通過director封裝步驟，通過builder封裝產品部分的實現，再把他兩隔離開，就能隔離變的，留出不變的供客戶端使用。
1.隔離了構建的步驟和具體的實現，為產品的具體實現提供了靈活度。
2.封裝和抽象了每個步驟的實現，實現了依賴倒轉原則。
3.封裝了具體的步驟，減少了**的冗餘。
1.要求構建產品的步驟（演算法）是不能劇烈變化的，最好是不變的，這樣就影響了靈活度。
**如下
設計模式 建造者模式C 實現
將乙個複雜物件的構建和他的表示分離，使得同樣的構建過程可以創造不同的表示 注 在模板方法中，實現了父類呼叫子類方法的功能，且，通過鉤子實現了方法的選擇性呼叫。但是其中整體的順序固定的，先做什麼再做什麼，不用做的通過鉤子遮蔽。而創造者模式就是對這個固定順序進行調整使得其更好工作的乙個模式。角色分工 p...
C 設計模式之 建造者模式
將乙個複雜物件的構建與它的表示分離，使得同樣的構建過程可以建立不同的表示 它主要用於建立一些複雜物件，這些物件內部構建間的建造順序通常是穩定的，但物件內部的構建通常面臨著複雜的變化。它使得建造 與表示 分離，由於建造者隱藏了該產品是如何組裝的，所以若需要改變乙個產品的內部表示，只需要再定義乙個具體的...
C 設計模式之建造者模式
一句話特點 萬丈高樓平地起 舉個栗子 需求 做出遊戲公司的各個職位之間的關係.畫圖 與之類似的還有uimanager,gamemanager等等,都是通過底層不斷累積產生的,像是造房子,具體 就不演示了.注 實現過程就和做遊戲一樣,先有boss,在去找專案經理,接著主程,主美,主策,再往下 再注 可...