每一個人的需求都不同
好比咱們如今已經用程序實現了一個汽車啓動的全過程：啓動，發動引擎，鳴笛，停車。具體實現可參考個人上篇文章「設計模式篇——模板方法模式詳解」。上面的順序是死的，只能按照啓動->發動引擎->鳴笛->停車的順序執行，顯然不能知足全部人的需求。好比張三習慣啓動後按一下喇叭，而李四習慣先按下喇叭在啓動，這就致使上面的程序不能同時知足兩人的要求。全部，咱們這裏要實現可讓客戶本身定義執行順序的需求。設計模式
咱們來整理一下思路，首先，無論客戶的需求是什麼樣子的，汽車的功能是不會變的，永遠都有啓動、發動引擎、鳴笛和停車的功能，因此，咱們能夠把這些共有的行爲抽象到父類定義，具體怎麼實現交給子類去重寫便可。而後，因爲張三和李四想要按不一樣的順序執行汽車的四個方法，因此，咱們能夠提供一個有序的集合，裏面存放用戶自定義的方法執行順序，最後遍歷這個有序集合不就能夠了。好，開始設計類圖：微信
抽象父類中定義一個成員變量 sequence 保存方法的執行順序，由客戶去設置它的值。具體源代碼以下。架構
抽象父類AbstractCar：ui
子類只需各自實現汽車的四個功能便可。代碼以下：spa
客戶調用端代碼：.net
上面的程序已經知足了隨意調整汽車啓動順序的需求，但細想一下，是否是以爲有些瑕疵？每一個客戶買完車以後都要本身去設置它的啓動順序，好比說這個設置操做很複雜，必須通過專業的培訓才能學會如何設置，那不是讓客戶發狂嗎。因此，咱們想要達到的效果是客戶須要什麼啓動順序直接告訴造車廠的人，在建造汽車的時候就把這個順序設置好就好了。因而，建造者模式就閃亮登場了。設計
建造者模式
建造者模式也叫生產器模式，它是將一個複雜對象的構建與它的表示分離，使得一樣的構建過程能夠建立不一樣的表示。建造者模式有一個通用的類圖，以下：3d
建造者模式中，有以下4個角色：orm
1. Product 產品類，一般是實現了模板方法模式，也就是有模板方法和基本方法。就像上面例子中的汽車類。關於模板方法模式能夠閱讀個人上篇文章「設計模式篇——模板方法模式詳解」。對象
2. Builder 抽象建造者，它是規範產品的組件，通常是由子類實現。
3. ConcreteBuilder 具體建造者，實現抽象 Builder 定義的全部方法，而且返回一個組件好的對象。
4. Director 導演類，負責安排已有模塊的順序，而後告訴 Builder 開始建造。
建造者模式的通用代碼也很簡單，先看 Product 產品類，一般它是一個組合或繼承產生的類：
抽象建造者 Builder 代碼：
其中，setPart 方法就是零件的配置，什麼是零件？其餘的對象，得到一個不一樣的零件，或者不一樣的裝配順序就可能產生不一樣的產品。
具體建造者 ConcreteBuilder 代碼：
注意：若是有多個產品類，就要有多個建造者，並且這多個產品類實現了相同的接口或父類。
導演類 Director 代碼：
導演類起到封裝的做用，避免高層模塊深刻到建造者內部的實現類。當建造者模式比較龐大時，導演類能夠有多個。
基於建造者模式改造例子代碼
接下來，咱們就一塊兒基於建造者模式改造上面生產汽車的代碼。首先改造咱們的類圖：
其中，AbstractCar 及其子類 Car一、Car2 代碼不變，咱們只看新增的類的代碼。
抽象汽車建造類 CarBuilder 代碼以下：
不一樣執行順序的車輛模型的組裝者 Car1Builder、Car2Builder代碼以下：
下面是直接與客戶交互，獲取具體車輛模型的導演類的代碼：
OK，改造完成，調用方使用起來是否是方便多了，只須要獲取一輛車，而後就能夠運行了。
建造者模式的使用場景
建造者模式具備如下優勢：
1. 封裝性好，客戶端沒必要知道內部產品的實現細節。
2. 建造者獨立，容易擴展。
3. 便於控制細節風險。
知道了它的優勢，再來講說何時用建造者模式：
1. 相同的方法，不一樣的執行順序，產生不一樣的事件結果時，能夠採用建造者模式。
2. 多個部件或零件，均可以裝配到一個對象中，可是產生的運行結果又不相同時，則可使用該模式。
3. 產品類很是複雜，或者產品類中的調用順序不一樣產生了不一樣的效能，這個時候使用建造者模式很是合適。
4. 在對象建立過程當中會使用到系統中的一些其餘對象，這些對象在產品對象的建立過程當中不易獲得時，也能夠採用建造者模式封裝該對象的建立過程。
點個關注吧，我會持續更新更多幹貨~~
本文分享自微信公衆號 - Java架構成長之路（K469785635）。
若有侵權，請聯繫 support@oschina.cn 刪除。
本文參與「OSC源創計劃」，歡迎正在閱讀的你也加入，一塊兒分享。