[[401366]]

前言

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

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

大綱

定義

什么是責(zé)任鏈?它的原理是什么?

• 將請求的發(fā)送和接收解耦，讓多個接收對象都有機會處理這個請求。將這些接收對象串成一條鏈，并沿著這條鏈傳遞這個請求，直到鏈上的某個接收對象能夠處理它為止。
• 以上定義來自《設(shè)計模式之美》

再看看一張官方圖解吧

• Client(客戶端)：實例化一個處理器的鏈，在第一個鏈對象中調(diào)用handleRequest 方法。
• Handle(處理器)：抽象類，提供給實際處理器繼承然后實現(xiàn)handleRequst方法，處理請求
• ConcreteHandler(具體處理器)：繼承了handler的類，同時實現(xiàn)handleRequst方法，負(fù)責(zé)處理業(yè)務(wù)邏輯類，不同業(yè)務(wù)模塊有不同的ConcreteHandler。

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

代碼實現(xiàn)

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

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) { 
        // 條件判斷是否是屬于當(dāng)前Handler的處理范圍之內(nèi)，不是則向下傳遞Handler處理器 
        if(times ==1){ 
          // 假設(shè)這里是處理的業(yè)務(wù)邏輯代碼 
            System.out.println("第一次面試"+times); 
        } 
        handler.handleRequest(times); 
    } 
} 

其次構(gòu)建第一次面試Handler，內(nèi)部實現(xiàn)handleRequest方法，判斷一下是否是當(dāng)前處理應(yīng)該處理的業(yè)務(wù)邏輯，不是則向下傳遞。同樣的第二次的SecondInterview和FirstInterview代碼基本是一致的，我就不給大家貼出來了，直接看最后一個

public class ThreeInterview extends Handler { 
    @Override 
    public void handleRequest(Integer times) { 
        if (times == 3) { 
            System.out.println("第三次面試"+ times + "，恭喜面試通過，HR會跟你聯(lián)      系?。。?quot;); 
        } 
    } 
 
    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(); 
    } 
} 

這個結(jié)果可以很明顯的看出，根據(jù)我們傳參，不同的Handler根據(jù)自己的職責(zé)處理著自己的業(yè)務(wù)，這就是責(zé)任鏈。

框架的應(yīng)用

責(zé)任鏈在很多框架源碼中也有體現(xiàn)。比如開始學(xué)SpringMVC中的 ServletFilter

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

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

給大家一個思考問題?

• dubbo服務(wù)一旦暴露出去了，那么基本任何服務(wù)都能調(diào)用，但是在一些特殊的業(yè)務(wù)中需要我們暴露服務(wù)，但是又不希望被不了解業(yè)務(wù)的人隨便調(diào)用。
• 比如：商品的庫存修改的dubbo服務(wù)，我們只允許下單，購物車，添加修改商品等一些指定場景可以調(diào)用。
• 那么有什么辦法，在Provider這端做好攔截，針對特定的服務(wù)才允許調(diào)用，否則攔截下來不允許執(zhí)行?

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

第二種方法，實現(xiàn)一個DUBBO攔截器，對RPC調(diào)用進行選擇性過濾。

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

先修改ConsumerContextFilter消費者攔截器

這里我們以dubbo的2.7.19版本為例。在ConsumerContextFilter中添加APP_NAME至Attachments中，那么作為本次的RPC調(diào)用都能從Attachments中獲取到我們?nèi)氲闹怠?/p>

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

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

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

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

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

現(xiàn)實業(yè)務(wù)改造舉例

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

還是給大家舉一個例子：

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

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

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

首先我們還是定一個抽象數(shù)據(jù)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("模擬數(shù)據(jù)請求")); 
       result.put("itemInfoHandler",itemInfoHandler.doRequest("模擬數(shù)據(jù)請求")); 
       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)); 
      // 打印的結(jié)果數(shù)據(jù) 
      // {"skuInfoHandler":{"skuId":78910,"skuName":"測試SKU"},"itemInfoHandler":{"itemId":123456,"itemName":"測試商品"}} 
    } 
} 

這個例子其實是經(jīng)過一點小小的改動的，我們沒有通過向下傳遞處理器的方式，而是通過實際業(yè)務(wù)邏輯在 convertItemDetail 的方法中去構(gòu)建每個模塊的數(shù)據(jù)，最后返回出一個Map結(jié)構(gòu)數(shù)據(jù)。

這里其實還有另外的一種寫法，把每一個需要處理的Handler 可以加載到一個List容器中，然后循環(huán)調(diào)用每個Handler中的doRequest方法，當(dāng)然這是針對一些其他的業(yè)務(wù)場景這么寫。

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

總結(jié)

設(shè)計模式不是一成不變的，只有適合自己當(dāng)前業(yè)務(wù)的模式才是最好的模式。理解前輩的思想，組合我們自己需要的模式。

本次分享就到這里了，后面接著為大家分享行為型設(shè)計模式。