場景描述：有乙個方法，要用到乙個物件，我們要生成它，比如是汽車，我們要用到的汽車，它的一些屬性是不止一種的，如配件等級的不同等
方式一： 因為汽車物件有這些屬性的set方法，我們直接通過多句set語句，來構造出我們需要的定製物件，但有乙個問題，乙個是**挺長，在乙個只是要獲取物件的地方而不是構造物件的地方使用了多句set來構造物件，這應該是不好的；還有是，如果其他地方的**也要用到定製物件，則要再set一遍，重複；
方式二： builder模式，其實就是將這些set方法封裝到乙個builder類中，同樣的介面，不同定製物件有不同的實現，即不同的屬性配置，這樣，在我們上面的場景，只要使用特定的構造器，就可以簡單的獲取到想要的定製物件，不用其他的多餘**，這樣**簡潔，也跟靈活，其他地方也可以用
就像麻辣燙中的各種**搭配，我們不用乙個乙個的去點，選擇相應的**即可，對需要生成物件的**塊來說，這樣是簡潔的。
上面是簡單理解。
和策略模式不同，策略模式的目的是選擇判斷一種執行方式，而生成器模式的目的是生成物件。
生成器模式更適合用於複雜物件的構建。
假設這個複雜物件的生成有固定流程，有很多個步驟，而且可能是靈活組合使用物件的屬性，那我們就不能單純的用set方法來構建物件，這時我們需要乙個指導類，裡面有乙個builder物件，用於獲取屬性，然後有構造複雜物件的方法，方法中將這多步的、複雜的、對屬性的靈活組合的過程組合起來，並最終返回乙個我們想要的物件。
這時，在生成物件**處，就需要定義乙個構造器物件和指導類物件，將構造器物件傳給指導類，並呼叫指導類的生成物件方法來獲取物件，這樣，就對**處（即「使用者」）隱藏了複雜的構造過程，「使用者」不需關心構造流程。
雖然我們似乎可以直接用物件來代替builder物件，因為它的作用只有接收屬性值並賦值給目標物件（汽車），但我的理解是，用builder物件，就像上面的**，將一些特定的屬性組合起來，供「使用者」直接使用，是對目標物件屬性賦值的進一步封裝。
生成器模式 Builder
把複雜的物件的構建與其表示分離開，以便根據程式的需要在相同的建立過程中建立不同的表示。每個生成器必須有乙個相同的方法名稱。client 建立乙個 director 物件，指定乙個 build 物件，配置 director。當 product 需要生成時，director 通知該builder bui...
生成器模式 （Builder）
gof意圖 將乙個複雜物件的構建 director 與它的表示 builder 分離，使得同樣的構建過程 director定義的 可以建立不同的表示 builder在組裝的 構建與表示分離 角色 1 builder 為建造者，提供建造part的介面buildpart 建造產品的一部分，獲得建造結果的...
設計模式 生成器（Builder）
目的 在軟體開發的過程中不可避免地會碰到一些複雜的物件。如果直接去建立這些複雜的物件，會使 變得難於理解和維護，而且對於大多數使用者而言他們並不關心物件各個成員的建立過程。builder的作用就是將物件各個成員的建立和組裝過程分離，根據使用者的需求一步一步建立複雜的物件。使用者只需要指定型別就可以得...