建站
咨詢
售后
建站咨詢
新聞中心
大家好，我是每周在這里陪大家一起進(jìn)步的網(wǎng)管。
創(chuàng)新互聯(lián)主要從事成都網(wǎng)站設(shè)計(jì)、成都做網(wǎng)站、網(wǎng)頁設(shè)計(jì)、企業(yè)做網(wǎng)站、公司建網(wǎng)站等業(yè)務(wù)。立足成都服務(wù)黎平,十載網(wǎng)站建設(shè)經(jīng)驗(yàn),價(jià)格優(yōu)惠、服務(wù)專業(yè),歡迎來電咨詢建站服務(wù):13518219792
今天繼續(xù)更新設(shè)計(jì)模式相關(guān)的文章，我在前面兩篇關(guān)于模板模式和策略模式的文章里給大家說過一個(gè)我總結(jié)的"暴論"：“模板、策略和職責(zé)鏈三個(gè)設(shè)計(jì)模式是解決業(yè)務(wù)系統(tǒng)流程復(fù)雜多變這個(gè)痛點(diǎn)的利器”。這篇文章我們就來一起說說這第三個(gè)設(shè)計(jì)模式利器—職責(zé)鏈模式。
職責(zé)鏈模式
職責(zé)鏈——英文名 Chain of responsibility 有時(shí)也被翻譯成責(zé)任鏈模式。我看網(wǎng)上叫責(zé)任鏈的更多一些，這里大家知道它們是一個(gè)東西就行了。
它是一種行為型設(shè)計(jì)模式。使用這個(gè)模式，我們能為請求創(chuàng)建一條由多個(gè)處理器組成的鏈路，每個(gè)處理器各自負(fù)責(zé)自己的職責(zé)，相互之間沒有耦合，完成自己任務(wù)后請求對象即傳遞到鏈路的下一個(gè)處理器進(jìn)行處理。
職責(zé)鏈在很多流行框架里都有被用到，像中間件、攔截器等框架組件都是應(yīng)用的這種設(shè)計(jì)模式，這兩個(gè)組價(jià)大家應(yīng)該用的比較多。在做Web 接口開發(fā)的時(shí)候，像記錄訪問日志、解析Token、格式化接口響應(yīng)的統(tǒng)一結(jié)構(gòu)這些類似的項(xiàng)目公共操都是在中間件、攔截器里完成的，這樣就能讓這些基礎(chǔ)操作與接口的業(yè)務(wù)邏輯進(jìn)行解耦。
中間件、攔截器這些組件都是框架給我們設(shè)計(jì)好的直接往里面套就可以，今天我們的文章里要講的是，怎么把職責(zé)鏈應(yīng)用到我們核心的業(yè)務(wù)流程設(shè)計(jì)中，而不僅僅是只做那些基礎(chǔ)的公共操作。
職責(zé)鏈的價(jià)值
上面我們說了職責(zé)鏈在項(xiàng)目公共組件中的一些應(yīng)用，讓我們能在核心邏輯的前置和后置流程中增加一些基礎(chǔ)的通用功能。但其實(shí)在一些核心的業(yè)務(wù)中，應(yīng)用職責(zé)鏈模式能夠讓我們無痛地?cái)U(kuò)展業(yè)務(wù)流程的步驟。
比如淘寶在剛剛創(chuàng)立的時(shí)候購物生成訂單處理流程起初可能是這樣的。
職責(zé)鏈模式—購物下單—清純版
整個(gè)流程比較干凈"用戶參數(shù)校驗(yàn)--購物車數(shù)據(jù)校驗(yàn)--商品庫存校驗(yàn)--運(yùn)費(fèi)計(jì)算--扣庫存—生成訂單"，我們姑且把它稱為清純版的購物下單流程，這通常都是在產(chǎn)品從0到1的時(shí)候，流程比較清純，在線購物你能實(shí)現(xiàn)在線選品、下單、支付這些就行了。
不過大家都是互聯(lián)網(wǎng)沖浪老手了，也都是吃過見過的主，這個(gè)流程要是一直這么清純，公司的PM和運(yùn)營就可以走人了。等購物網(wǎng)站跑起來，有消費(fèi)者了之后，為了提高銷售額，一般會加一些，某些品類商品滿減的促銷手段。
運(yùn)營也不能閑著，多談點(diǎn)客戶，造個(gè)購物節(jié)，到時(shí)候優(yōu)惠券安排上多吸引點(diǎn)用戶。那這樣在下訂單的流程中，就得判斷購物車?yán)锏纳唐肥欠駶M足折扣條件、用戶是否有優(yōu)惠卷，有的話進(jìn)行金額減免。相當(dāng)于我們下單的內(nèi)部流程中間加了兩個(gè)子流程。
職責(zé)鏈模式—購物下單—老練版
為了實(shí)現(xiàn)新加的邏輯，我們就得在寫好的訂單流程中最起碼加兩個(gè) if else 分支才能加上這兩個(gè)邏輯。不過最要命的是因?yàn)檎麄€(gè)流程耦合在一起，修改了以后我們就得把整個(gè)流程全測一遍。并且有了上面的經(jīng)驗(yàn)我們也應(yīng)該知道這個(gè)流程以后肯定還會擴(kuò)展，比如再給你加上社群砍一刀、拼單這些功能，以后每次在訂單生成流程中加入步驟都得修改已經(jīng)寫好的代碼，怕不怕？
有朋友可能會說，互聯(lián)網(wǎng)電商購物可能確實(shí)流程比較多樣化，每個(gè)公司的流程不一樣。我們再舉個(gè)病人去醫(yī)院看病的例子，病人看病大體上基本步驟需要有：
掛號—>診室看病—>收費(fèi)處繳費(fèi)—>藥房拿藥
但是有可能有的病人需要化驗(yàn)、拍片子等等，他們在醫(yī)院就醫(yī)的流程可能是這樣的：
掛號—>初診—>影像科拍片—>復(fù)診室—>收費(fèi)處繳費(fèi)—>藥房拿藥
所以就醫(yī)這個(gè)流程也是會根據(jù)病人情況的不同，步驟有所增加的。
那么現(xiàn)在我們可以確定：假如一個(gè)流程的步驟不固定，為了在流程中增加步驟時(shí)，不必修改原有已經(jīng)開發(fā)好，經(jīng)過測試的流程，我們需要讓整個(gè)流程中的各個(gè)步驟解耦，來增加流程的擴(kuò)展性，這種時(shí)候就可以使用職責(zé)鏈模式啦，這個(gè)模式可以讓我們先設(shè)置流程鏈路中有哪些步驟，再去執(zhí)行。
用職責(zé)鏈模式實(shí)現(xiàn)流程
如果讓我們設(shè)計(jì)責(zé)任鏈應(yīng)該怎么設(shè)計(jì)呢？應(yīng)該提供和實(shí)現(xiàn)哪些方法？怎么使用它把流程里的步驟串起來呢？這里我們用職責(zé)鏈模式把就診看病這個(gè)場景中的流程步驟實(shí)現(xiàn)一遍給大家做個(gè)演示，購物下單的流程類似，咱們下去可以自己嘗試實(shí)現(xiàn)一遍，先學(xué)會職責(zé)鏈模式的結(jié)構(gòu)做些Mock示例，掌握熟練了后面再嘗試著用它解決業(yè)務(wù)中的問題。
首先我們通過上面流程擴(kuò)展的痛點(diǎn)可以想到，流程中每個(gè)步驟都應(yīng)由一個(gè)處理對象來完成邏輯抽象、所有處理對象都應(yīng)該提供統(tǒng)一的處理自身邏輯的方法，其次還應(yīng)該維護(hù)指向下一個(gè)處理對象的引用，當(dāng)前步驟自己邏輯處理完后，就調(diào)用下一個(gè)對象的處理方法，把請求交給后面的對象進(jìn)行處理，依次遞進(jìn)直到流程結(jié)束。
總結(jié)下來，實(shí)現(xiàn)責(zé)任鏈模式的對象最起碼需要包含如下特性：
- 成員屬性
nextHandler: 下一個(gè)等待被調(diào)用的對象實(shí)例
- 成員方法
SetNext?: 把下一個(gè)對象的實(shí)例綁定到當(dāng)前對象的nextHandler屬性上；
Do: 當(dāng)前對象業(yè)務(wù)邏輯入口，他是每個(gè)處理對象實(shí)現(xiàn)自己邏輯的地方；
Execute?: 負(fù)責(zé)職責(zé)鏈上請求的處理和傳遞；它會調(diào)用當(dāng)前對象的Do，nextHandler?不為空則調(diào)用nextHandler.Do；
如果抽象成 UML 類圖表示的話，差不多就是下面這個(gè)樣子。
定義了一個(gè)職責(zé)鏈模式處理對象的接口?Handler?，由ConcreteHandler --具體處理對象的類型來實(shí)現(xiàn)。
觀察上圖以及上面對象特性的分析，其實(shí)是能看出 SetNext? 和 Execute? 這兩個(gè)行為是每個(gè) ConcreteHandler 都一樣的，所以這兩個(gè)可以交給抽象處理類型來實(shí)現(xiàn)，每個(gè)具體處理對象再繼承抽象類型，即可減少重復(fù)操作。
所以責(zé)任鏈模式的抽象和提煉可以進(jìn)化成下圖這樣：
了解完職責(zé)鏈模式從接口和類型設(shè)計(jì)上應(yīng)該怎么實(shí)現(xiàn)后，我們進(jìn)入代碼實(shí)現(xiàn)環(huán)節(jié)，職責(zé)鏈模式如果用純面向?qū)ο蟮恼Z言實(shí)現(xiàn)起來還是很方便的，把上面的UML類圖直接翻譯成接口、抽象類，再搞幾個(gè)實(shí)現(xiàn)類就完事。
想把上面這個(gè)UML類圖翻譯成Go代碼還是有點(diǎn)難度的。這里咱們提供一個(gè)用 Go 實(shí)現(xiàn)職責(zé)鏈模式完成醫(yī)院就診流程的代碼示例。
職責(zé)鏈 Go 代碼實(shí)現(xiàn)
雖然 Go 不支持繼承，不過我們還是能用類型的匿名組合來實(shí)現(xiàn)，下面以病人去醫(yī)院看病這個(gè)處理流程為例提供一個(gè)具體示例。
看病的具體流程如下：
掛號—>診室看病—>收費(fèi)處繳費(fèi)—>藥房拿藥
我們的目標(biāo)是利用責(zé)任鏈模式，實(shí)現(xiàn)這個(gè)流程中的每個(gè)步驟，且相互間不耦合，還支持向流程中增加步驟。
先來實(shí)現(xiàn)職責(zé)鏈模式里的公共部分—即模式的接口和抽象類
"本文使用的完整可運(yùn)行源碼
去公眾號「網(wǎng)管叨bi叨」發(fā)送【設(shè)計(jì)模式】即可領(lǐng)取"
type PatientHandler interface {
Execute(*patient) error
SetNext(PatientHandler) PatientHandler
Do(*patient) error
}
// 充當(dāng)抽象類型，實(shí)現(xiàn)公共方法，抽象方法不實(shí)現(xiàn)留給實(shí)現(xiàn)類自己實(shí)現(xiàn)
type Next struct {
nextHandler PatientHandler
}
func (n *Next) SetNext(handler PatientHandler) PatientHandler {
n.nextHandler = handler
return handler
}
func (n *Next) Execute(patient *patient) (err error) {
// 調(diào)用不到外部類型的 Do 方法，所以 Next 不能實(shí)現(xiàn) Do 方法
if n.nextHandler != nil {
if err = n.nextHandler.Do(patient); err != nil {
return
}
return n.nextHandler.Execute(patient)
}
return
}
上面代碼中Next?類型充當(dāng)了模式中抽象類的角色，關(guān)于這個(gè)Next類型這里再重點(diǎn)說明一下。
在我們的職責(zé)鏈的UML圖里有說明Do?方法是一個(gè)抽象方法，留給具體處理請求的類來實(shí)現(xiàn)，所以這里Next?類型充當(dāng)抽象類型，只實(shí)現(xiàn)公共方法，抽象方法留給實(shí)現(xiàn)類自己實(shí)現(xiàn)。并且由于 Go 并不支持繼承，即使Next?實(shí)現(xiàn)了Do?方法，也不能達(dá)到在父類方法中調(diào)用子類方法的效果—即在我們的例子里面用Next? 類型的Execute?方法調(diào)用不到外部實(shí)現(xiàn)類型的Do方法。
所以我們這里選擇Next?類型直接不實(shí)現(xiàn)Do方法，這也是在暗示這個(gè)類型是專門用作讓實(shí)現(xiàn)類進(jìn)行內(nèi)嵌組合使用的。
接下來我們定義職責(zé)鏈要處理的請求，再回看一下我們的UML圖，實(shí)現(xiàn)處理邏輯和請求傳遞的Do、Execute方法的參數(shù)都是流程中要處理的請求。這里是醫(yī)院接診的流程，所以我們定義一個(gè)患者類作為流程的請求。
//流程中的請求類--患者
type patient struct {
Name string
RegistrationDone bool
DoctorCheckUpDone bool
MedicineDone bool
PaymentDone bool
}
然后我們按照掛號—>診室看病—>收費(fèi)處繳費(fèi)—>藥房拿藥這個(gè)流程定義四個(gè)步驟的處理類，來分別實(shí)現(xiàn)每個(gè)環(huán)節(jié)的邏輯。
"本文使用的完整可運(yùn)行源碼
去公眾號「網(wǎng)管叨bi叨」發(fā)送【設(shè)計(jì)模式】即可領(lǐng)取"
// Reception 掛號處處理器
type Reception struct {
Next
}
func (r *Reception) Do(p *patient) (err error) {
if p.RegistrationDone {
fmt.Println("Patient registration already done")
return
}
fmt.Println("Reception registering patient")
p.RegistrationDone = true
return
}
// Clinic 診室處理器--用于醫(yī)生給病人看病
type Clinic struct {
Next
}
func (d *Clinic) Do(p *patient) (err error) {
if p.DoctorCheckUpDone {
fmt.Println("Doctor checkup already done")
return
}
fmt.Println("Doctor checking patient")
p.DoctorCheckUpDone = true
return
}
// Cashier 收費(fèi)處處理器
type Cashier struct {
Next
}
func (c *Cashier) Do(p *patient) (err error) {
if p.PaymentDone {
fmt.Println("Payment Done")
return
}
fmt.Println("Cashier getting money from patient patient")
p.PaymentDone = true
return
}
// Pharmacy 藥房處理器
type Pharmacy struct {
Next
}
func (m *Pharmacy) Do (p *patient) (err error) {
if p.MedicineDone {
fmt.Println("Medicine already given to patient")
return
}
fmt.Println("Pharmacy giving medicine to patient")
p.MedicineDone = true
return
}
處理器定義好了，怎么給用他們串成患者就診這個(gè)流程呢？
func main() {
receptionHandler := &Reception{}
patient := &patient{Name: "abc"}
// 設(shè)置病人看病的鏈路
receptionHandler.SetNext(&Clinic{}).SetNext(&Cashier{}).SetNext(&Pharmacy{})
receptionHandler.Execute(patient)
}上面的鏈?zhǔn)秸{(diào)用看起來是不是很清爽，嘿嘿別高興太早，這里邊有個(gè)BUG— 即Recepiton?接診掛號這個(gè)步驟提供的邏輯沒有調(diào)用到，所以我們這里再定義個(gè)StartHandler? 類型，它不提供處理實(shí)現(xiàn)只是作為第一個(gè)Handler向下轉(zhuǎn)發(fā)請求
"本文使用的完整可運(yùn)行源碼
去公眾號「網(wǎng)管叨bi叨」發(fā)送【設(shè)計(jì)模式】即可領(lǐng)取"
// StartHandler 不做操作，作為第一個(gè)Handler向下轉(zhuǎn)發(fā)請求
type StartHandler struct {
Next
}
// Do 空Handler的Do
func (h *StartHandler) Do(c *patient) (err error) {
// 空Handler 這里什么也不做 只是載體 do nothing...
return
}
這也是Go 語法限制，公共方法Exeute?并不能像面向?qū)ο竽菢酉日{(diào)用this.Do? 再調(diào)用this.nextHandler.Do 具體原因咱們上邊已經(jīng)解釋過了，如果覺得不清楚的可以拿Java實(shí)現(xiàn)一遍看看區(qū)別，再琢磨一下為啥Go里邊不行。
所以整個(gè)流程每個(gè)環(huán)節(jié)都能被正確執(zhí)行到，應(yīng)該這樣把處理類串起來。
"本文使用的完整可運(yùn)行源碼
去公眾號「網(wǎng)管叨bi叨」發(fā)送【設(shè)計(jì)模式】即可領(lǐng)取"
func main() {
patientHealthHandler := StartHandler{}
//
patient := &patient{Name: "abc"}
// 設(shè)置病人看病的鏈路
patientHealthHandler.SetNext(&Reception{}).// 掛號
SetNext(&Clinic{}). // 診室看病
SetNext(&Cashier{}). // 收費(fèi)處交錢
SetNext(&Pharmacy{}) // 藥房拿藥
//還可以擴(kuò)展，比如中間加入化驗(yàn)科化驗(yàn)，圖像科拍片等等
// 執(zhí)行上面設(shè)置好的業(yè)務(wù)流程
if err := patientHealthHandler.Execute(patient); err != nil {
// 異常
fmt.Println("Fail | Error:" + err.Error())
return
}
// 成功
fmt.Println("Success")
}
本文的完整源碼，已經(jīng)同步收錄到我整理的電子教程里啦，可向我的公眾號「網(wǎng)管叨bi叨」發(fā)送關(guān)鍵字【設(shè)計(jì)模式】領(lǐng)取。
總結(jié)
職責(zé)鏈模式所擁有的特點(diǎn)讓流程中的每個(gè)處理節(jié)點(diǎn)都只需關(guān)注滿足自己處理?xiàng)l件的請求進(jìn)行處理即可，對于不感興趣的請求，會直接轉(zhuǎn)發(fā)給下一個(gè)節(jié)點(diǎn)對象進(jìn)行處理。
另外職責(zé)鏈也可以設(shè)置中止條件，針對我們文中的例子就是在Execute方法里加判斷，一旦滿足中止后就不再繼續(xù)往鏈路的下級節(jié)點(diǎn)傳遞請求。Gin 的中間件的abort方法就是按照這個(gè)原理實(shí)現(xiàn)的，同時(shí)這也是職責(zé)鏈跟裝飾器模式的一個(gè)區(qū)別，裝飾器模式無法在增強(qiáng)實(shí)體的過程中停止，只能執(zhí)行完整個(gè)裝飾鏈路。
后面大家可以看看針對那些可能未來經(jīng)常會變的核心業(yè)務(wù)流程，可以在設(shè)計(jì)初期就考慮使用職責(zé)鏈來實(shí)現(xiàn)，減輕未來流程不停迭代時(shí)不好擴(kuò)展的痛點(diǎn)。當(dāng)然職責(zé)鏈也不是萬能的，對于那些固定的流程顯然是不適合的。咱們千萬不要手里拿著錘子就看什么都是釘子，所有的設(shè)計(jì)模式一定要用在合適的地方。
既然這里提到了裝飾器，那么下一期就寫寫裝飾器吧，不對，裝飾器算是代理模式的一個(gè)特殊應(yīng)用，那就還是先介紹代理未來再介紹裝飾器吧，這樣閱讀體驗(yàn)會更好一些。
新聞名稱：你也是業(yè)務(wù)開發(fā)？提前用這個(gè)設(shè)計(jì)模式預(yù)防產(chǎn)品加需求吧
本文鏈接：http://www.dlmjj.cn/article/dheedeh.html
