建造者模式(Builder Pattern)

建造者模式(Builder Pattern)

它能夠將多個簡單的對象一步一步構建成一個複雜的對象。

意圖：將一個複雜的構建與其表示相分離，使得一樣的構建過程能夠建立不一樣的表示。

主要解決：主要解決在軟件系統中，有時候面臨着"一個複雜對象"的建立工做，其一般由各個部分的子對象用必定的算法構成；因爲需求的變化，這個複雜對象的各個部分常常面臨着劇烈的變化，可是將它們組合在一塊兒的算法卻相對穩定。

什麼時候使用：一些基本部件不會變，而其組合常常變化的時候。

如何解決：將變與不變分離開。

關鍵代碼：建造者：建立和提供實例，導演：管理建造出來的實例的依賴關係。

應用實例： JAVA 中的 StringBuilder等。

優勢： 一、建造者獨立，易擴展。 二、便於控制細節風險。

缺點： 一、產品必須有共同點，範圍有限制。 二、如內部變化複雜，會有不少的建造類。

使用場景： 一、須要生成的對象具備複雜的內部結構。 二、須要生成的對象內部屬性自己相互依賴。

注意事項：與工廠模式的區別是：建造者模式更加關注與零件裝配的順序。

　　在咱們實際編程開發過程當中須要調用許多前人已經寫好的類或接口來完善咱們某些特殊的需求，這就比如咱們去餐館裏吃飯（開發），點了一桌閤家歡套餐（需求），桌上的飯菜裏面一定有肉食，蔬菜類，主食，湯類等等（pojo，JavaBean，entity等），咱們不關心飯菜是怎樣製做的（底層代碼的具體實現邏輯和 數據），咱們只管吃喝玩樂（調用和吐槽）。大多數人並無耐心和精力去肯定每個菜品的選擇，套餐無疑是一個簡單方便效率高的選擇，這時候若是餐館經理（director）告訴咱們有「奢華套餐」和「普通套餐」或其餘什麼套餐（封裝成類或接口）等多種選擇，咱們會根據自身條件和需求自主選擇要哪一個套餐。這個過程當中，餐館經理（director）已經將各個菜品封裝好，而後端上桌子供咱們享受，不管奢華套餐仍是普通套餐都還有肉食，蔬菜類，主食，湯類等要素。

　　這無形中提升了餐館的營業效率和壓縮顧客的點餐時間成本，餐館內部分工方面，廚師仍是作原來的菜（基礎類工廠），新產生的職位拼菜工（director內部方法）將菜品封裝（調用封裝類）。若是餐館須要一位能作不一樣口味的廚師，能作更多的菜，產生更多的套餐，那咱們只需向餐館經理（director）提意見就行了.

　　最後，我本身也蒙圈了，這個比喻有些許不恰當的地方，初出茅廬，還請大神指正。以上只是我本身的理解。總之建造者模式的精髓仍是告誡人們不要重複造輪子，讓你們享受更便捷的開發環境。

 

 

 

 

參考資料：http://www.runoob.com/design-pattern/builder-pattern.html

https://blog.csdn.net/u010102390/article/details/80179754