[[398716]]

本文轉(zhuǎn)載自微信公眾號(hào)「三太子敖丙」，作者三太子敖丙。轉(zhuǎn)載本文請(qǐng)聯(lián)系三太子敖丙公眾號(hào)。

為什么要學(xué)設(shè)計(jì)模式?設(shè)計(jì)模式有哪些優(yōu)點(diǎn)?

• 提升查看框架源碼能力
• 提升自己對(duì)復(fù)雜業(yè)務(wù)代碼設(shè)計(jì)能力以及code能力
• 對(duì)今后面試以及職場(chǎng)道路打下扎實(shí)的基礎(chǔ)

這是我之前寫工廠模式的時(shí)候給大家提的一些優(yōu)點(diǎn)，感興趣的伙伴可以再去復(fù)習(xí)一下。

今天我們要講的是設(shè)計(jì)模式中三種模式(創(chuàng)建型模式、行為型模式、結(jié)構(gòu)型模式)中的創(chuàng)建型模式中的建造者模式，也可以叫 Builder模式。

與其他的創(chuàng)建型模式比如工廠模式一樣都是用來(lái)服務(wù)相同的目標(biāo)，但是他們的作用場(chǎng)景不一樣，實(shí)現(xiàn)方式不一樣而已，但最終的目的都是一個(gè)：就是為了讓我們寫出結(jié)構(gòu)嚴(yán)謹(jǐn)，易懂且易擴(kuò)展的高質(zhì)量代碼。

建造者模式

什么叫建造者?他的應(yīng)用場(chǎng)景又是什么呢?

當(dāng)我們需要實(shí)列化一個(gè)復(fù)雜的類，以得到不同結(jié)構(gòu)類型和不同的內(nèi)部狀態(tài)的對(duì)象時(shí)，我們可以用不同的類對(duì)它們的實(shí)列化操作邏輯分別進(jìn)行封裝，這些類我們就稱之為建造者。

當(dāng)我們需要來(lái)之同一個(gè)類，但是要就有不同結(jié)構(gòu)對(duì)象時(shí)，就可以通過(guò)構(gòu)造另一個(gè)建造者來(lái)進(jìn)行實(shí)列化。

----------以上定義來(lái)自《設(shè)計(jì)模式之美》。

為了加深理解我們?cè)賮?lái)一個(gè)流程圖

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

Product(產(chǎn)品類) :我們具體需要生成的類對(duì)象

Builder(抽象建造者類)：為我們需要生成的類對(duì)象，構(gòu)建不同的模塊屬性，即：公開(kāi)構(gòu)建產(chǎn)品類的屬性，隱藏產(chǎn)品類的其他功能

ConcreteBuilder(具體建造者類)：實(shí)現(xiàn)我們要生成的類對(duì)象

Director(導(dǎo)演類)：確定構(gòu)建我們的類對(duì)象具體有哪些模塊屬性，在實(shí)際應(yīng)用中可以不需要這個(gè)角色，直接通過(guò)client處理

舉例

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

那我們要怎么實(shí)現(xiàn)這種這種創(chuàng)建商品呢?

我們先看下最普通的創(chuàng)建方式：

我們先創(chuàng)建一個(gè)基礎(chǔ)商品Item類：

這里我們可以看到根據(jù)請(qǐng)求類型，也可以完全創(chuàng)建出我們想要的類型商品，但是一個(gè)商品屬性不可能只有這么一點(diǎn)屬性，那以后擴(kuò)展更多呢?那這個(gè)代碼我們看上去就會(huì)很臃腫，也不好維護(hù)。

接下來(lái)我們就看下建造者模式怎么去實(shí)現(xiàn)：

第一步：創(chuàng)建我們的抽象建造者類。這里面我們看下有三個(gè)抽象方法，來(lái)確定不同的商品類型，我們調(diào)用不同的方法，達(dá)到解偶的思想

第二步：創(chuàng)建具體建造者類。對(duì)抽象建造者類的抽象方法進(jìn)行實(shí)現(xiàn)賦值，達(dá)到我們所需要的結(jié)果。

第三步：創(chuàng)建我們的導(dǎo)演類。指導(dǎo)我們?cè)趺慈?chuàng)建對(duì)象，這個(gè)我們是可以簡(jiǎn)化的，視具體使用場(chǎng)景確定吧!

最后就是看我們的測(cè)試結(jié)果了。在省略導(dǎo)演類的時(shí)候其實(shí)我們也完全可以的構(gòu)建出我們想要的結(jié)果，因?yàn)槲疫@寫的是測(cè)試demo所以沒(méi)有寫傳參，這個(gè)大家可以根據(jù)自己的實(shí)際應(yīng)用場(chǎng)景去做改造。

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

舉例二：

假設(shè)我們現(xiàn)在有另外的一種場(chǎng)景，我們復(fù)制一個(gè)商品時(shí)，當(dāng)沒(méi)有填寫庫(kù)存時(shí)我們默認(rèn)是0，當(dāng)用戶填寫了時(shí)我們庫(kù)存數(shù)量不能大于999999999。

那我們要怎么去實(shí)現(xiàn)呢?

PS：商品復(fù)制這個(gè)功能在電商領(lǐng)域是很普通的一個(gè)操作，對(duì)用戶來(lái)說(shuō)簡(jiǎn)化操作成本，提升用戶體檢。技術(shù)服務(wù)于業(yè)務(wù)，業(yè)務(wù)決定公司的長(zhǎng)遠(yuǎn)利益

我們?cè)趦?nèi)部創(chuàng)建了一個(gè)ItemBuilder，來(lái)處理我們的校驗(yàn)邏輯。當(dāng)然我們使用普通的get，set方式其實(shí)也是可以實(shí)現(xiàn)的。

看到這里可能有人會(huì)問(wèn)這個(gè)與我們使用get或者set方法又有什么區(qū)別呢?

解釋：主要是為了解決我們的賦值處于一種無(wú)效狀態(tài)

無(wú)效狀態(tài)指的是對(duì)象屬性之間存在依賴關(guān)系，合法校驗(yàn)等，如果使用set方式會(huì)導(dǎo)致這種關(guān)系和校驗(yàn)得不到驗(yàn)證，所有可能會(huì)存在無(wú)效的狀態(tài)，即A、B兩個(gè)屬性必須同時(shí)設(shè)置，缺一不可，然后set方法可能導(dǎo)致遺漏等

總結(jié)

以上就是我要跟大家了解的建造者模式，其實(shí)我還是想跟大家分享這種思想吧，像第二個(gè)列子大家也可以用于寫配置文件(比如我們的鏈接池，里面很多必填或者不必填參數(shù)，同時(shí)也可以避免在因?yàn)閷傩灾颠^(guò)多而寫構(gòu)造方法時(shí)產(chǎn)生不好維護(hù)，不雅觀的現(xiàn)象)等，因?yàn)槲乙恢痹陔娚坦竟ぷ?，所以我舉的列子都是以電商為主。

只有我們了解了每種設(shè)計(jì)模式解決了什么問(wèn)題，我們才知道哪種場(chǎng)景用什么模式或者多種設(shè)計(jì)模式進(jìn)行組合，避免產(chǎn)生因強(qiáng)行使用設(shè)計(jì)模式，反而使得代碼更加的不好維護(hù)了。