今天要認識的模式是Chain of Responsibility，屬於Behavioral Design Pattern，它的名字很長，我覺得很好認，而且也不難，現在就一起來認識它吧！

問題情境與解析

　　原本你的應用程式從客戶端發送請求後，會需要經過一些資料處理的步驟，才能存入系統的資料庫中，而這些資料處理的步驟可能會因為系統不斷的更新，而導致步驟的順序變更，抑或是添加新的檢驗步驟來增加系統的安全性，因此這個檢驗的程式就會變得非常難以維護且又不好理解，你必須得重構這整件事情。

　　使用責任鏈模式的話，會將每個檢查的步驟封裝成一個獨立的類別，其他的請求及數據就用參數的方式來傳遞給類別中的方法。而這些檢查步驟會串成一個鏈結，而且擁有下一個檢查步驟物件的屬性，因此客戶端的請求會沿著鏈結一直傳遞下去，每個節點都有機會去處理這個請求。

　　Chain of Responsibility在這個例子中，可以隨時添加新的檢查步驟，也可以移除或修改步驟的方法，甚至是重新調整檢查步驟的順序，端看應用程式的邏輯做動態更新，是不是非常方便呢！

Class Diagram

Skeleton Code

abstract class Handler {
    private Handler next;
    
    public Handler(Handler next) {
        this.next = next;
    }
    
    public void handleRequest() {
        if (next != null) {
            next.handleRequest();
        }
    }
}

class HandlerA extends Handler {
    
    public HandlerA(Handler next) {
        super(next);
    }
    
    public void handleRequest() {
        if (canHandleRquest()) {
            // do something
        } else {
            super.handleRequest();
        }
    }
}

class HandlerB extends Handler {
    
    public HandlerB(Handler next) {
        super(next);
    }
    
    public void handleRequest() {
        if (canHandleRquest()) {
            // do something
        } else {
            super.handleRequest();
        }
    }
}

　　責任鏈模式可以實現較鬆散的耦合設計，來自客戶端的請求會被傳遞到鏈結中的物件，接著由這些物件去判定該給誰去處理，以及是否需要給下一個物件來處理請求。若要動態修改鏈結中的物件或是調整其順序也是可以接受的，提升了程式整體的靈活性，不過鏈結中的物件也有可能都沒辦法處理來自客戶端的請求，這也是此模式的缺點之一。

除此之外，也歡迎大家走走逛逛關於我們團隊夥伴的文章

lu23770127 - SASS 基礎初學三十天

10u1 - 糟了！是世界奇觀！

juck30808 - Python - 數位行銷分析與 Youtube API 教學

SiQing47 - 前端？後端？你早晚都要全端的，何不從現在開始？