设计模式之建造者
建造者(生成器)模式
含義:生成器模式是一種創(chuàng)建型模式,使你能夠分步奏創(chuàng)建復(fù)雜對象,可使用相同的創(chuàng)建代碼生成不同類型和形式的對象。
看圖我們就能很好地理解,圖中就是工廠中的流水線模式,建造者就好比整條流水線,通過流水線上每個裝配點(diǎn)的工人將一個個產(chǎn)品零件組裝整合成一個完整的產(chǎn)品即可。
將對象構(gòu)造代碼從具體產(chǎn)品類中抽取出來,并將其放在一個名為生成器的獨(dú)立對象中。
它可以讓你能夠分步奏創(chuàng)建復(fù)雜對象,不允許其他對象訪問正在創(chuàng)建中的產(chǎn)品。
利用相同的物料,不同的組裝所產(chǎn)生出的具體內(nèi)容,就是建造者模式的最終體現(xiàn)。
將一個復(fù)雜的構(gòu)建與其表示分離,使得同樣的構(gòu)建過程可以創(chuàng)建不同的表示。
生成器模式結(jié)構(gòu)
生成器(Builder)接口聲明在所有類型生成器中通用的產(chǎn)品構(gòu)造步奏。
具體生成器(Concrete Builders)提供構(gòu)造過程的不同實(shí)現(xiàn),具體生成器也可以構(gòu)造不遵循通用接口的產(chǎn)品。
產(chǎn)品(Products)是最終生成的對象。由不同生成器構(gòu)造的產(chǎn)品無需數(shù)據(jù)同一類層次結(jié)構(gòu)或接口。
主管(Director)類定義調(diào)用構(gòu)造步奏的順序,這樣就可以創(chuàng)建和復(fù)用特定的產(chǎn)品配置。
建造者模式主要解決的問題是在軟件系統(tǒng)中,有時候面臨著一個復(fù)雜對象的創(chuàng)建工作,其通常由各部分的子對象用一定的過程構(gòu)成;由于需求的變化,這個復(fù)雜對象的各個部分經(jīng)常面臨著重大的變化,但是將它們組合在一起的過程卻相對穩(wěn)定。
Demo展示
這里我就拿極速物流公司中發(fā)貨的過程來舉例,希望大家能對建造者模式有一個很好的理解。
小A去物流公司發(fā)貨,他手里面的貨物要發(fā)送到3個不同的地方,物流公司會根據(jù)不同地區(qū)有不同的收費(fèi)標(biāo)準(zhǔn)。可是對于小A來說,他不需要管那些,只需要將三件東西交給收貨員,填寫好各自貨物的收件地址就OK,收貨員通過計算出不同收件地址的收費(fèi)情況給出報價單,告訴小A應(yīng)付多少錢,小A只需要付款就可以。
這里不同地區(qū)收費(fèi)不一樣給出報價單的業(yè)務(wù)就可以使用我們剛剛學(xué)習(xí)到的建造者模式來實(shí)現(xiàn),由于不同地方的運(yùn)輸路徑,發(fā)貨方式,包裝方式等不同,則收費(fèi)標(biāo)準(zhǔn)也是不一樣的。
類結(jié)構(gòu)描述
發(fā)貨貨物類(基本屬性)
發(fā)貨抽象類(生成器)
各自不同地區(qū)的收費(fèi)類(具體生成器,生成器的實(shí)現(xiàn)類)
發(fā)貨的控制類(主管)
上面羅列出的就是各個類的具體代碼實(shí)現(xiàn),下面是測試,目前以北京地區(qū)發(fā)貨舉例。
????class?Program{static?void?Main(string[]?args){SendModelBuilder?smb?=?new?BeiJingBuilder();JiSuWuLiuController?director?=?new?JiSuWuLiuController();Matter?matter?=?director.SendModel(smb);Console.WriteLine("包裝類型:"+matter.PackStyle);Console.WriteLine("運(yùn)輸方式:"?+?matter.TransportWay);Console.WriteLine("是否有稅費(fèi):"?+?matter.IsHaveTax);Console.WriteLine("運(yùn)費(fèi):"?+?matter.Money);Console.WriteLine("信息:"+matter.DescriptionInfo);Console.ReadKey();}} 測試結(jié)果可以看到,我們在實(shí)現(xiàn)的時候,只是去聲明并由directior來調(diào)用了BeiJingBuilder的創(chuàng)建者,具體的業(yè)務(wù)也只是單獨(dú)在BeiJingBuilder類中去實(shí)現(xiàn)。如果我們想換成其余地區(qū)的發(fā)貨,則只需要將聲明換掉就可以。
小結(jié)
優(yōu)點(diǎn):
客戶端不需要知道產(chǎn)品內(nèi)部的組成細(xì)節(jié),將產(chǎn)品本身與產(chǎn)品的創(chuàng)建進(jìn)行分離,也就是解耦,使得相同的創(chuàng)建過程可以創(chuàng)建不同的產(chǎn)品對象。
具體構(gòu)建獨(dú)立,增加新的建造者不需要修改原有庫,系統(tǒng)擴(kuò)展方便,符合開閉原則。
控制產(chǎn)品的創(chuàng)建過程很方便。
缺點(diǎn):
當(dāng)產(chǎn)品比較多時,導(dǎo)致代碼比較冗余,系統(tǒng)變得過于龐大,增加系統(tǒng)的理解難度和運(yùn)行成本。
此模式主要適用于當(dāng)各自產(chǎn)品有一定共性的時候,如果產(chǎn)品獨(dú)立性太強(qiáng),無相同共性則不適合這個模式。
小寄語
人生短暫,我不想去追求自己看不見的,我只想抓住我能看的見的。
我是阿輝,感謝您的閱讀,如果對你有幫助,麻煩點(diǎn)贊、轉(zhuǎn)發(fā) ?謝謝。
總結(jié)
- 上一篇: 如何让 dotnetcore 在 Lin
- 下一篇: 设计模式之原型