面臨問題：如何提供一種「封裝機制」來隔離出「複雜物件的各個部分」的變化，從而保持系統中的「穩定構建演算法」不隨著需求改變而改變？
也就是說乙個複雜的物件，各個部分變化，但是將他們組合在一起的演算法比較穩定，這時候，我們應該採取什麼機制去建立乙個複雜的物件？
舉個例子自行車就是‚乙個複雜物件‛，它有車輪和車架組成，但不管車輪和車架這兩個部件怎麼變化，生產一輛自行車的過程是不會變的，即組裝過程是不會變的。我們需要做的時候隨著需求的變化，我們怎麼生產這個複雜物件？我想要鳳凰牌自行車，我想要永久牌的自行車的時候呢？
解決方案：建造者模式可以將乙個產品的內部表象與產品的生成過程分割開來，從而可以使乙個建造過程生成具有不同的內部表象的產品物件。
也就是說，需要建立乙個director物件，來指揮建立乙個最後的複雜產品，director通過例項化不同的具體builder，完成不同的複雜產品。這些產品的建造過程都是相似的，所以我們每個具體的建造類，都是繼承自乙個抽象的建造類。對於每個具體建造類所需要的零件到底是什麼，需要具體的建造類，去例項化每個零件產品。
舉個例子，我是客戶，我想買自行車，我必須例項化乙個builder物件，即要建造乙個永久牌自行車，我還要例項化乙個director物件，然後告訴這個物件給我建造乙個永久牌自行車，然後我就不管了，我通過呼叫director物件的construct()方法就能獲得一輛永久牌自行車。
對於director的工作過程，在construct方法中通過呼叫永久牌自行車的建造過程，建造完之後，返回getresult。
對於建造永久牌自行車的過程，我必須有乙個產品類。然後有很多零件，我通過建造的每乙個步驟，對這個產品進行組裝，最後返回這個物件，也就是永久牌自行車。
上面的圖builder和concretebuilder都缺少了乙個product屬性。
builder對應於組裝自行車所使用的車輪和車架
concretebuiler1對應於永久牌車輪和車架，同時可以返回一輛永久牌自行車，concretebuiler2對應於鳳凰牌車輪和車架，同時可以返
回一輛鳳凰牌自行車
product對應於自行車
director表示組裝過程。
前面我們說過的抽象工廠模式（abtract factory）解決系列物件的需求變化，builder模式解決物件部分的需求變化，建造者模式常和組合模式（composite
pattern）結合使用。
如果產品的內部變化複雜，可能會導致需要定義很多具體建造者類來實現這種變化，導致系統變得很龐大
應用例項：
在聯機射擊遊戲中每乙個遊戲人物角色都需要提供乙個完整的角色造型，包括人物造型、服裝、**等，如何建立乙個完整的遊戲角色？
審題:是建立乙個角色，而這個角色是由很多部分組成的，而且部分是變化的。所以要採用builder模式。
顯然遊戲人物是乙個複雜的產品，需要很多零件，包括造型，服裝，**，但是每個遊戲人物建造的過程都是相似的。
具體解決辦法參考上圖。很好設計的。
建造者模式
1.定義 將乙個複雜物件的構建與它的表示分離，使得同樣的構建過程可以建立不同的表示。2.uml 類圖 結構 該結構 演示了複雜物件被一步一步建立的建造者模式。builder pattern structural example using system using system.collection...
建造者模式
軟體領域中的設計模式為開發人員提供了一種使用專家設計經驗的有效途徑。設計模式中運用了物件導向程式設計語言的重要特性 封裝 繼承 多型，真正領悟設計模式的精髓是可能乙個漫長的過程，需要大量實踐經驗的積累。最近看設計模式的書，對於每個模式，用c 寫了個小例子，加深一下理解。主要參考 大話設計模式 和 設...
建造者模式
建造者模式將複雜物件的構建和它的表示分離，使同樣的構建過程能夠構建出不同的表示。以乙個建造小人為例子，可以建造2種小人，胖子和瘦子 include using namespace std class builder 抽象建造者類 class buildthinman public builder 瘦...