[[398716]]

本文轉載自微信公眾號「三太子敖丙」，作者三太子敖丙。轉載本文請聯系三太子敖丙公眾號。

為什么要學設計模式?設計模式有哪些優點?

• 提升查看框架源碼能力
• 提升自己對復雜業務代碼設計能力以及code能力
• 對今后面試以及職場道路打下扎實的基礎

這是我之前寫工廠模式的時候給大家提的一些優點，感興趣的伙伴可以再去復習一下。

今天我們要講的是設計模式中三種模式(創建型模式、行為型模式、結構型模式)中的創建型模式中的建造者模式，也可以叫 Builder模式。

與其他的創建型模式比如工廠模式一樣都是用來服務相同的目標，但是他們的作用場景不一樣，實現方式不一樣而已，但最終的目的都是一個：就是為了讓我們寫出結構嚴謹，易懂且易擴展的高質量代碼。

建造者模式

什么叫建造者?他的應用場景又是什么呢?

當我們需要實列化一個復雜的類，以得到不同結構類型和不同的內部狀態的對象時，我們可以用不同的類對它們的實列化操作邏輯分別進行封裝，這些類我們就稱之為建造者。

當我們需要來之同一個類，但是要就有不同結構對象時，就可以通過構造另一個建造者來進行實列化。

----------以上定義來自《設計模式之美》。

為了加深理解我們再來一個流程圖

從圖中我們主以看出建造者主要分為4種角色：

Product(產品類) :我們具體需要生成的類對象

Builder(抽象建造者類)：為我們需要生成的類對象，構建不同的模塊屬性，即：公開構建產品類的屬性，隱藏產品類的其他功能

ConcreteBuilder(具體建造者類)：實現我們要生成的類對象

Director(導演類)：確定構建我們的類對象具體有哪些模塊屬性，在實際應用中可以不需要這個角色，直接通過client處理

舉例

在電商中有多種不同類型的商品 普通實物商品，電子卡券商品，虛擬視頻學習商品 等多種不同的商品，他們都是商品但是他們的屬性卻不一樣，電子卡券：獨有券碼，學習視頻：獨有視頻鏈接等。

那我們要怎么實現這種這種創建商品呢?

我們先看下最普通的創建方式：

我們先創建一個基礎商品Item類：

這里我們可以看到根據請求類型，也可以完全創建出我們想要的類型商品，但是一個商品屬性不可能只有這么一點屬性，那以后擴展更多呢?那這個代碼我們看上去就會很臃腫，也不好維護。

接下來我們就看下建造者模式怎么去實現：

第一步：創建我們的抽象建造者類。這里面我們看下有三個抽象方法，來確定不同的商品類型，我們調用不同的方法，達到解偶的思想

第二步：創建具體建造者類。對抽象建造者類的抽象方法進行實現賦值，達到我們所需要的結果。

第三步：創建我們的導演類。指導我們怎么去創建對象，這個我們是可以簡化的，視具體使用場景確定吧!

最后就是看我們的測試結果了。在省略導演類的時候其實我們也完全可以的構建出我們想要的結果，因為我這寫的是測試demo所以沒有寫傳參，這個大家可以根據自己的實際應用場景去做改造。

與普通的寫法相比建造者模式的寫法使的這個代碼可讀性高，而且易擴展，不同類型的商品達到了解耦合的效果。

舉例二：

假設我們現在有另外的一種場景，我們復制一個商品時，當沒有填寫庫存時我們默認是0，當用戶填寫了時我們庫存數量不能大于999999999。

那我們要怎么去實現呢?

PS：商品復制這個功能在電商領域是很普通的一個操作，對用戶來說簡化操作成本，提升用戶體檢。技術服務于業務，業務決定公司的長遠利益

我們在內部創建了一個ItemBuilder，來處理我們的校驗邏輯。當然我們使用普通的get，set方式其實也是可以實現的。

看到這里可能有人會問這個與我們使用get或者set方法又有什么區別呢?

解釋：主要是為了解決我們的賦值處于一種無效狀態

無效狀態指的是對象屬性之間存在依賴關系，合法校驗等，如果使用set方式會導致這種關系和校驗得不到驗證，所有可能會存在無效的狀態，即A、B兩個屬性必須同時設置，缺一不可，然后set方法可能導致遺漏等

總結

以上就是我要跟大家了解的建造者模式，其實我還是想跟大家分享這種思想吧，像第二個列子大家也可以用于寫配置文件(比如我們的鏈接池，里面很多必填或者不必填參數，同時也可以避免在因為屬性值過多而寫構造方法時產生不好維護，不雅觀的現象)等，因為我一直在電商公司工作，所以我舉的列子都是以電商為主。

只有我們了解了每種設計模式解決了什么問題，我們才知道哪種場景用什么模式或者多種設計模式進行組合，避免產生因強行使用設計模式，反而使得代碼更加的不好維護了。