什么是責任鏈模式

這篇文章主要講解了“什么是責任鏈模式”，文中的講解內容簡單清晰，易于學習與理解，下面請大家跟著小編的思路慢慢深入，一起來研究和學習“什么是責任鏈模式”吧！

前言

面試經歷大家肯定都有過，但是面試的流程其實跟一種設計模式很像，每一輪的面試官都有自己的職責，一個求職者面試經歷的過程就好比一次客戶端的請求過程。

在設計模式系列的文章中之前已經為大家分享了創建型設計模式，感興趣的小伙伴們可以再去翻看之前的分享。接下來開始分享設計模式三大類型中的行為型模式了，今天要分享的是責任鏈模式

大綱

定義

什么是責任鏈?它的原理是什么?

• 將請求的發送和接收解耦，讓多個接收對象都有機會處理這個請求。將這些接收對象串成一條鏈，并沿著這條鏈傳遞這個請求，直到鏈上的某個接收對象能夠處理它為止。

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

再看看一張官方圖解吧

• Client(客戶端)：實例化一個處理器的鏈，在第一個鏈對象中調用handleRequest 方法。

• Handle(處理器)：抽象類，提供給實際處理器繼承然后實現handleRequst方法，處理請求

• ConcreteHandler(具體處理器)：繼承了handler的類，同時實現handleRequst方法，負責處理業務邏輯類，不同業務模塊有不同的ConcreteHandler。

這么看結構其實還是比較簡單的，但是我們還是拿面試的流程來模擬一下責任鏈吧!

代碼實現

假設現在去一家公司面試，第一次去一面，第二次去二面，第三次去直接過了。那這個模擬面試代碼怎么寫呢?

public abstract class Handler {      protected Handler handler;      public void setHandler(Handler handler) {         this.handler = handler;     }     public abstract void handleRequest(Integer times); }

首先我們還是定義一個抽象Handler處理器，同時添加一個抽象處理方法  handleRequest，后面我只需要編寫具體的處理器來繼承Handler類

public class FirstInterview extends Handler {     @Override     public void handleRequest(Integer times) {         // 條件判斷是否是屬于當前Handler的處理范圍之內，不是則向下傳遞Handler處理器         if(times ==1){           // 假設這里是處理的業務邏輯代碼             System.out.println("第一次面試"+times);         }         handler.handleRequest(times);     } }

其次構建第一次面試Handler，內部實現handleRequest方法，判斷一下是否是當前處理應該處理的業務邏輯，不是則向下傳遞。同樣的第二次的SecondInterview和FirstInterview代碼基本是一致的，我就不給大家貼出來了，直接看最后一個

public class ThreeInterview extends Handler {     @Override     public void handleRequest(Integer times) {         if (times == 3) {             System.out.println("第三次面試"+ times + "，恭喜面試通過，HR會跟你聯      系！！！");         }     }      public static void main(String[] args) {         Handler first = new FirstInterview();         Handler second = new SecondInterview();         Handler three = new ThreeInterview();         first.setHandler(second);         second.setHandler(three);          // 第一次面試         first.handleRequest(1);         System.out.println();         // 第二次面試         first.handleRequest(2);         System.out.println();         // 第三次面試         first.handleRequest(3);         System.out.println();     } }

這個結果可以很明顯的看出，根據我們傳參，不同的Handler根據自己的職責處理著自己的業務，這就是責任鏈。

框架的應用

責任鏈在很多框架源碼中也有體現。比如開始學SpringMVC中的 ServletFilter

以及Spring中的 SpringInterceptor 這里面其實都是運用了責任鏈模式的思想，達到框架的可擴展性的同時也遵循著開閉原則。

作為常見的RPC框架的DUBBO其實里面也同樣有這個責任鏈的思想。

給大家一個思考問題?

• dubbo服務一旦暴露出去了，那么基本任何服務都能調用，但是在一些特殊的業務中需要我們暴露服務，但是又不希望被不了解業務的人隨便調用。

• 比如：商品的庫存修改的dubbo服務，我們只允許下單，購物車，添加修改商品等一些指定場景可以調用。

• 那么有什么辦法，在Provider這端做好攔截，針對特定的服務才允許調用，否則攔截下來不允許執行?

第一種方法，添加服務名稱APP_NAME作為傳參校驗，這是很常見也最容易想到的辦法。

第二種方法，實現一個DUBBO攔截器，對RPC調用進行選擇性過濾。

針對上面的兩種方法，給大家詳細講講第二種方法具體怎么實現，每個公司都會基于現有的DUBBO源碼做自己的特定化改動，那么第二種方式也是同樣需要我們改動線有dubbo源碼。

先修改ConsumerContextFilter消費者攔截器

這里我們以dubbo的2.7.19版本為例。在ConsumerContextFilter中添加APP_NAME至Attachments中，那么作為本次的RPC調用都能從Attachments中獲取到我們塞入的值。

至于這個APP_NAME的獲取 可以通過 System.getProperty("project.name", "") 來獲取服務名

• 這里我就不對DUBBO做過多的展開，大家如果有強烈建議講解。那么在結束設計模式再跟大家詳細剖析一下dubbo，以及zookeeper里面的ZAB，一致性選舉算法等等。

CONSUMER既然已經填充了服務名稱，那么在Provider同樣的也就只需要寫一個ProviderFilter 就可以了

這里就基本實現怎么處理每一次RPC調用的攔截了，然后想要那個服務攔截，在provider里面的filter里面指定一下這個DubboProviderFilter就可以了，也可以全局都實現。

注意 ：這個Filter 要是用DUBBO包里面的，不要搞錯了。

現實業務改造舉例

框架中既然都有這種思想，那么怎么運用到業務代碼中呢?

還是給大家舉一個例子：

商品詳情展示我們可以是分模塊展示的，比如頭圖，商品信息，sku信息，配送地址，分期付費等等。

那么怎么進行組裝到商品詳情的展示呢?

public abstract class AbstractDataHandler<T> {      // 處理模塊化數據     protected abstract T doRequest(String query) throws Exception; }

首先我們還是定一個抽象數據Handler，然后分別建立ItemInfoHandler 和SkuInfoHandler 來繼承抽象處理器

@Component public class ItemInfoHandler extends AbstractDataHandler<ItemInfoHandler.ItemInfo> {     @Override     protected ItemInfoHandler.ItemInfo doRequest(String query) {         ItemInfoHandler.ItemInfo info = new ItemInfo();         info.setItemId(123456L);         info.setItemName("測試商品");         return info;     }      @Data     public static class ItemInfo {         private Long itemId;         private String itemName;     } }

同樣SkuInfoHandler類也是一樣的

@Component public class SkuInfoHandler extends AbstractDataHandler<SkuInfoHandler.SkuInfo> {     @Override     protected SkuInfoHandler.SkuInfo doRequest(String query) {         SkuInfoHandler.SkuInfo info = new SkuInfoHandler.SkuInfo();         info.setSkuId(78910L);         info.setSkuName("測試SKU");         return info;     }     @Data     public static class SkuInfo {         private Long skuId;         private String skuName;     } }

最后就是我們的測試代碼了

@Component public class DataAggregation {     @Autowired     private SkuInfoHandler skuInfoHandler;     @Autowired     private ItemInfoHandler itemInfoHandler;      public Map convertItemDetail() throws Exception {        Map result = new HashMap();        result.put("skuInfoHandler", skuInfoHandler.doRequest("模擬數據請求"));        result.put("itemInfoHandler",itemInfoHandler.doRequest("模擬數據請求"));        return result;     }      public static void main(String[] args) throws Exception {         ApplicationContext applicationContext = new ClassPathXmlApplicationContext("classpath:applicationContext.xml");         DataAggregation dataAggregation = (DataAggregation) applicationContext.getBean("dataAggregation");         Map map = dataAggregation.convertItemDetail();         System.out.println(JSON.toJSONString(map));       // 打印的結果數據       // {"skuInfoHandler":{"skuId":78910,"skuName":"測試SKU"},"itemInfoHandler":{"itemId":123456,"itemName":"測試商品"}}     } }

這個例子其實是經過一點小小的改動的，我們沒有通過向下傳遞處理器的方式，而是通過實際業務邏輯在 convertItemDetail  的方法中去構建每個模塊的數據，最后返回出一個Map結構數據。

這里其實還有另外的一種寫法，把每一個需要處理的Handler  可以加載到一個List容器中，然后循環調用每個Handler中的doRequest方法，當然這是針對一些其他的業務場景這么寫。

看完大家也能發現其實每個Handler是可以共用的，每一塊業務的代碼邏輯非常的清晰，這樣的代碼寫出來就感覺很舒服了。

總結

設計模式不是一成不變的，只有適合自己當前業務的模式才是最好的模式。理解前輩的思想，組合我們自己需要的模式。

感謝各位的閱讀，以上就是“什么是責任鏈模式”的內容了，經過本文的學習后，相信大家對什么是責任鏈模式這一問題有了更深刻的體會，具體使用情況還需要大家實踐驗證。這里是億速云，小編將為大家推送更多相關知識點的文章，歡迎關注！