真实的国产乱ⅩXXX66竹夫人,五月香六月婷婷激情综合,亚洲日本VA一区二区三区,亚洲精品一区二区三区麻豆

成都創(chuàng)新互聯(lián)網(wǎng)站制作重慶分公司

ChainofResponsibility職責鏈模式怎么實現(xiàn)

本文小編為大家詳細介紹“Chain of Responsibility職責鏈模式怎么實現(xiàn)”,內(nèi)容詳細,步驟清晰,細節(jié)處理妥當,希望這篇“Chain of Responsibility職責鏈模式怎么實現(xiàn)”文章能幫助大家解決疑惑,下面跟著小編的思路慢慢深入,一起來學習新知識吧。

創(chuàng)新互聯(lián)主要從事網(wǎng)頁設計、PC網(wǎng)站建設(電腦版網(wǎng)站建設)、wap網(wǎng)站建設(手機版網(wǎng)站建設)、成都響應式網(wǎng)站建設、程序開發(fā)、網(wǎng)站優(yōu)化、微網(wǎng)站、重慶小程序開發(fā)公司等,憑借多年來在互聯(lián)網(wǎng)的打拼,我們在互聯(lián)網(wǎng)網(wǎng)站建設行業(yè)積累了豐富的網(wǎng)站設計制作、成都網(wǎng)站建設、網(wǎng)站設計、網(wǎng)絡營銷經(jīng)驗,集策劃、開發(fā)、設計、營銷、管理等多方位專業(yè)化運作于一體。

Chain of Responsibility(職責鏈模式)

Chain of Responsibility(職責鏈模式)屬于行為型模式。行為型模式不僅描述對象或類的模式,還描述它們之間的通信模式,比如對操作的處理應該如何傳遞等等。

意圖:使多個對象都有機會處理請求,從而避免請求的發(fā)送者和接收者之間的耦合關系。將這些對象連成一條鏈,并沿著這條鏈傳遞該請求,直到有一個對象處理它為止。

幾乎所有設計模式,在了解到它之前,筆者就已經(jīng)在實戰(zhàn)中遇到過了,因此設計模式的確是從實踐中得出的真知。但另一方面,如果沒有實戰(zhàn)的理解,單看設計模式是枯燥的,而且難以理解的,因此大家學習設計模式時,要結合實際問題思考。

舉例子

如果看不懂上面的意圖介紹,沒有關系,設計模式需要在日常工作里用起來,結合例子可以加深你的理解,下面我準備了三個例子,讓你體會什么場景下會用到這種設計模式。

中間件機制

設想我們要為一個后端框架實現(xiàn)中間件(知道 Koa 的同學可以理解為 Koa 的洋蔥模型),在代碼中可以插入任意多個中間件,每個中間件都可以對請求與響應進行處理。

由于每個中間件只響應自己感興趣的請求,因此只有運行時才知道這個中間件是否會處理請求,那么中間件機制應該如何設計,才能保證其功能和靈活性呢?

通用幫助文案

如果一個大型系統(tǒng)中,任何一個模塊點擊都會彈出幫助文案,但并不是每個模塊都有幫助文案的,如果一個模塊沒有幫助文案,則顯示其父級的幫助文案,如果再沒有,就繼續(xù)冒泡到整個應用,展示應用級別的兜底幫助文案。這種系統(tǒng)應該如何設計?

JS 事件冒泡機制

其實 JS 事件冒泡機制就是個典型的職責鏈模式,因為任何 DOM 元素都可以監(jiān)聽比如 onClick,不僅可以自己響應事件,還可以使用 event.stopPropagation() 阻止繼續(xù)冒泡。

意圖解釋

JS 事件冒泡機制對前端來說太常見了,但我們換個角度,站在點擊事件的角度理解,就能重新發(fā)現(xiàn)其設計的精妙之處:

點擊事件是疊加在每層 dom 上的,由于 dom 對事件的處理和綁定是動態(tài)的,瀏覽器本身不知道哪些地方會處理點擊事件,但又要讓每層 dom 擁有對點擊事件的 “平等處理權”,所以就產(chǎn)生了冒泡機制,與事件阻止冒泡功能。

通用幫助文案和 JS 事件冒泡很類似,只是把點擊事件換成了彈出幫助文案罷了,其場景機理是一樣的。

說到這,我們可以再重新理解一下職責鏈模式的意圖:

意圖:使多個對象都有機會處理請求,從而避免請求的發(fā)送者和接收者之間的耦合關系。將這些對象連成一條鏈,并沿著這條鏈傳遞該請求,直到有一個對象處理它為止。

請求指的是某個觸發(fā)機制產(chǎn)生的請求,是一個通用概念?!氨苊庹埱蟮陌l(fā)送者和接收者之間的耦合關系”,指的是如果我們只有一個對象有處理請求的機會,那接收者就與發(fā)送者之間耦合了,其他接收者必須通過這個接收者才能繼續(xù)處理,這種模式不夠靈活。

后半句描述的是如何設計,可以實現(xiàn)這個靈活的模式,即將對象連成一條鏈,沿著鏈條傳遞該請求,直到有一個對象處理它為止。還要理解到,任何一個對象都擁有阻斷請求繼續(xù)傳遞的能力。

在中間件機制的例子中,后端 Web 框架對 Http 請求的處理就是個運用職責鏈模式的典型案例,因為后端框架要處理的請求是平行關系,任何請求都可能要求被響應,但對請求的處理是通過插件機制拓展的,且對每個請求的處理都是一個鏈條,存在處理、加工、再處理的邏輯關系。

結構圖

Handler 就是對請求的處理,可以看到這里是一條環(huán)路,只要處理完之后就可以交給下一個 Handler 進行處理,可以在中途攔截后中斷,也可以穿透整條鏈路。

ConcreteHandler 是具體 Handler 的實現(xiàn),他們都需要繼承 Handler 以具備相同的 HandleRequest 方法,這樣每一個處理中間件就都擁有了處理能力,使得這些對象連成的鏈條可以對請求進行傳遞。

代碼例子

職責鏈實現(xiàn)方式非常多,比如 Koa 的洋蔥模型實現(xiàn)原理就值得再寫一篇文章,感興趣的同學可以閱讀 co 源碼。這里僅介紹最簡單場景的實現(xiàn)方案。

職責鏈的簡單實現(xiàn)模式也分為兩種,一種是每個對象本身維護到下一個對象的引用,另一種是由 Handler 維護后繼者。

下面例子使用 typescript 編寫。

public class Handler {

  private nextHandler: Handler

  public handle() {

    if(nextHandler) {

      nextHandler.handle()

    }

  }

}

每個 Handler 的默認行為就是觸發(fā)下一個鏈條的 handle,因此什么都不做的話,這個鏈條是完全打通的,因此我們可以在鏈條的任何一環(huán)進行處理。

處理的方式就是重寫 handle 函數(shù),我們在重寫時,可以維持對 nextHandler.handle() 的調(diào)用,以使得鏈條繼續(xù)向后傳遞,也可以不調(diào)用,從而終止鏈條向后傳遞。

弊端

職責鏈模式不保證每個中間件都有機會處理請求,因為中間件順序的問題,后面中間件可能被前面的中間件阻斷,因此當中間件之間存在不信任關系時,職責鏈模式并不能保證中間件調(diào)用的可靠性。

另外就是不要擴大設計模式的使用范圍,對一堆對象的連續(xù)調(diào)用就沒必要使用職責鏈模式,因為職責鏈適合處理對象數(shù)量不確定、是否處理請求由每個對象靈活決定的場景,而確定了對象數(shù)量以及是否調(diào)用的場景,就沒必要使用職責鏈模式了。

讀到這里,這篇“Chain of Responsibility職責鏈模式怎么實現(xiàn)”文章已經(jīng)介紹完畢,想要掌握這篇文章的知識點還需要大家自己動手實踐使用過才能領會,如果想了解更多相關內(nèi)容的文章,歡迎關注創(chuàng)新互聯(lián)行業(yè)資訊頻道。


網(wǎng)站欄目:ChainofResponsibility職責鏈模式怎么實現(xiàn)
標題URL:http://weahome.cn/article/iiisij.html

其他資訊

在線咨詢

微信咨詢

電話咨詢

028-86922220(工作日)

18980820575(7×24)

提交需求

返回頂部