作為一個上班族，我們可能會經常聽到“管理流程混亂”，“職責邊界不清晰”等這樣或那樣的抱怨，這是當組織或系統發展壯大後，一件事由一個人或者一個部門無法獨立完成時，不得不面對的問題。就拿平時請假來說，試想如果是一個只有幾個人的小公司，很可能連請假條都不用寫，直接跟老闆說一下就OK了，但是如果公司有一定規模，做為一個小小的螺絲釘，就未必有資格面見老闆了，這時就不得不走審批流程了。我們都知道，通常情況下請假需要在OA上寫請假單交由各級領導審批，不同級別的領導有權審批的天數不同，例如不超過1天的請假直接領導（TL）審批就可以了，而大於1天不超過3天就需要整個專案的負責人（PM）審批才可以，當然時間更長的，如7天，則可能需要交由CTO甚至更高階的領導審批。

這個例子就已經體現出責任的劃分了，我們先用程式碼模擬一下這個請假場景，然後由此引出我們這次的主角---責任鏈模式。

示例

既然是請假，當然先得有請假單，而請假單又由申請和審批結果兩部分組成，分別由請假人和審批領導填寫，這不難理解，程式碼如下：

public class LeaveContext
{
    /// <summary>
    /// 申請
    /// </summary>
    public LeaveRequest Request { get; set; }

    /// <summary>
    /// 審批結果
    /// </summary>
    public LeaveResponse Response { get; set; }
}
 

然後再來幾個領導，每個領導都有在一定範圍內處理請求的能力。經過前面那麼多設計模式的薰陶，針對不同級別的領導抽象個管理者基類不難想到吧？

public abstract class Manager
{
    public string Name { get; set; }

    public Manager(string name)
    {
        Name = name;
    }

    public abstract void HandleRequest(LeaveContext context);
}

/// <summary>
/// 團隊領導者
/// </summary>
public class TL : Manager
{
    public TL(string name)
        : base(name)
    {
    }

    public override void HandleRequest(LeaveContext context)
    {
        if (context.Request.LeaveDays <= 1)
        {
            context.Response = new LeaveResponse
            {
                Approver = "TL:" + Name,
                IsAgreed = true
            };
        }
    }
}

/// <summary>
/// 專案經理
/// </summary>
public class PM : Manager
{
    public PM(string name)
        : base(name)
    {

    }

    public override void HandleRequest(LeaveContext context)
    {
        if (context.Request.LeaveDays > 1
            && context.Request.LeaveDays <= 3)
        {
            context.Response = new LeaveResponse
            {
                Approver = "PM:" + Name,
                IsAgreed = true
            };
        }
    }
}

/// <summary>
/// 首席技術官
/// </summary>
public class CTO : Manager
{
    public CTO(string name)
        : base(name)
    {

    }

    public override void HandleRequest(LeaveContext context)
    {
        if (context.Request.LeaveDays > 3
            && context.Request.LeaveDays <= 7)
        {
            context.Response = new LeaveResponse
            {
                Approver = "CTO:" + Name,
                IsAgreed = true
            };
        }
    }
}
 

每個領導都能對同一個請求進行處理，但是也各司其職，只做自己能力範圍內的事，並且處理請求的角度和方式也大不相同（即程式碼實現上有較大的差異，這個例子過於簡單，所以這點體現並不明顯）。

再來看看呼叫的地方：

static void Main(string[] args)
{
    LeaveContext context = new LeaveContext
    {
        Request = new LeaveRequest
        {
            Applicant = "張三",
            Reason = "世界那麼大，我想去看看",
            LeaveDays = new Random().Next(1, 10)
        }
    };

    TL tL = new TL("李四");
    PM pM = new PM("王五");
    CTO cTO = new CTO("趙六");
    if (context.Request.LeaveDays <= 1)
    {
        tL.HandleRequest(context);
    }
    else if (context.Request.LeaveDays <= 3)
    {
        pM.HandleRequest(context);
    }
    else if (context.Request.LeaveDays <= 7)
    {
        cTO.HandleRequest(context);
    }

    if (context.Response == null)
    {
        Console.WriteLine($"{context.Request.LeaveDays}天假期太長，沒人處理請假申請,請假失敗");
    }
    else
    {
        Console.WriteLine($"{context.Response.Approver}審批了{context.Request.Applicant}的{context.Request.LeaveDays}天請假申請");
    }
}

上述程式碼有點多，但基本思路就是例項化請假單和若干領導物件，然後根據請假天數判斷交給哪個領導處理，最後再將處理結果列印輸出。有興趣的話，不妨下載原始碼，多執行幾次看看結果，邏輯還是相當嚴謹的。

狀態模式改造

不過，邏輯雖然嚴謹，但作為一名優雅的程式設計師，我們不難挑出一些毛病，一方面，if...else太多，擴充套件性不好；另一方面，請假難度太大了，還容易出錯，實際上，請假者只是想請個假而已，他也不知道誰有權處理，請個假總感覺領導在相互甩鍋，管理可不就混亂了嗎？
不過對於這兩個問題，我們略微思索就會發現，前面遇到過，沒錯，就是狀態模式，只不過狀態模式是呼叫者不想關注系統內部狀態的變化，而這裡是不想關注內部審批流程的變化。狀態模式的解決思路是將狀態的設定轉移到系統內部，即在一個具體狀態類中處理完成對應的業務邏輯之後，設定下一個狀態，這裡不妨效仿一下。

public class TL : Manager
{
    public TL(string name)
        : base(name)
    {
    }

    public override void HandleRequest(LeaveContext context)
    {
        if (context.Request.LeaveDays <= 1)
        {
            context.Response = new LeaveResponse
            {
                Approver = "TL:" + Name,
                IsAgreed = true
            };
            return;
        }

        PM pM = new PM("王五");
        pM.HandleRequest(context);
    }
}

其他幾個管理者物件類似處理，這樣一來，呼叫者就簡單了，程式碼如下：

static void Main(string[] args)
{
    ...

    TL tL = new TL("李四");
    tL.HandleRequest(context);

    ...
}

不過，呼叫者雖然簡單了，但是把鍋甩給了管理者，不妨再看看上面的TL類，不難看出面向實現程式設計了，違背了迪米特原則，進而也就違背了開閉原則，記得在狀態模式中也同樣有這個問題，我們當時是通過享元模式解決的，原因是狀態是可以共享的，並且狀態是系統內部的，外部不應該知道的。而這裡情況有所不同，管理者物件是不可以共享的，外部也是可以訪問的，因此，處理手段也就不同了。我們在Manager基類中新增NextManager屬性，這也是一種依賴注入的手段，之前的設計模式我們用過了方法注入，建構函式注入，這是第三種注入方式---屬性注入。

public abstract class Manager
{
    public Manager NextManager { get; set; }

    ...
}

然後具體的實現類中，通過NextManager指向下一個管理者。下面以TL類為例：

public class TL : Manager
{
    ...

    public override void HandleRequest(LeaveContext context)
    {
        if (context.Request.LeaveDays <= 1)
        {
            context.Response = new LeaveResponse
            {
                Approver = "TL:" + Name,
                IsAgreed = true
            };
            return;
        }

        NextManager?.HandleRequest(context);
    }
}

這樣所有管理者類就又面向抽象程式設計，可以輕鬆擴充套件了。我們再來看看如何呼叫：

static void Main(string[] args)
{
    ...

    TL tL = new TL("李四");
    PM pM = new PM("王五");
    CTO cTO = new CTO("趙六");
    tL.NextManager = pM;
    pM.NextManager = cTO;

    tL.HandleRequest(context);

    ...
}

乍一看，心裡拔涼拔涼的，又變複雜了，好不容易甩出去的鍋又被甩回來了。不過呢，雖然有瑕疵，但相對於最開始的實現，還是好了很多，至少，請假時只需要找直接領導就可以了，審批細節也不用再關注了，這就是責任鏈模式，下面看一下類圖。

示例類圖

定義

多個物件都有機會處理某個請求，將這些物件連成一條鏈，並沿著這條鏈傳遞該請求，直到處理完成為止。責任鏈模式的核心就是“鏈”，是由多個處理者串起來組成。

類圖

• Handler：抽象處理者角色，是一個處理請求的介面或抽象類；
• ConcreteHandler：具體的處理者角色，具體的處理者接收到請求後可以選擇將請求處理掉，或者將請求傳遞給下一個處理者。

責任鏈模式+模板方法模式

通過前面的程式碼和定義，我們可以看到，責任鏈模式其實並不完善，首先管理者子類實現中有邏輯和程式碼上的重複，例如都需要判斷是否有權力處理請求，處理完之後都需要交給下一個處理者處理，並且這個流程是固定的。因此，我們可以進行如下改造，把公共固定的部分提取到基類中：

public abstract class Manager
{
    public Manager NextManager { get; set; }

    public string Name { get; set; }

    public Manager(string name)
    {
        Name = name;
    }

    public void HandleRequest(LeaveContext context)
    {
        if (CanHandle(context))
        {
            Handle(context);
            return;
        }

        NextManager?.HandleRequest(context);
    }

    protected abstract bool CanHandle(LeaveContext context);

    protected abstract void Handle(LeaveContext context);
}

上述程式碼將演算法骨架封裝到了HandleRequest(LeaveContext context)方法中，然後將演算法子步驟CanHandle(LeaveContext context)和Handle(LeaveContext context延時到子類中實現，當然，由於子步驟不應該被外部直接呼叫，因此訪問修飾符為protected，看到了嗎？這是標準的模板方法模式。
再來看看具體子類如何實現，還是以TL為例：

public class TL : Manager
{
    public TL(string name)
        : base(name)
    {
    }

    protected override bool CanHandle(LeaveContext context)
    {
        return context.Request.LeaveDays <= 1;
    }

    protected override void Handle(LeaveContext context)
    {
        context.Response = new LeaveResponse
        {
            Approver = "TL:" + Name,
            IsAgreed = true
        };
    }
}

子類更加乾淨清爽，職責也更加單一了，只需關心自己的處理邏輯，甚至都不用關心做完之後該交給誰，擴充套件起來更加容易了。

責任鏈模式+建造者模式

除此之外，另外一個問題其實更加明顯，就是前面說的鍋甩來甩去還是回到了呼叫者身上，雖說呼叫者不再需要知道每個領導的審批許可權範圍，但是除了指定自己的領導，還得指定領導的領導，領導的領導的領導，這其實也不合理，出現這個問題的原因是什麼呢？原因是不符合常理，我們忽略的一個很重要的部門---人力行政部（HR），請假流程應該是他們提前制定好的，而不是每次請假時臨時制定的。

因此，要解決這個問題，首先得加入一個HR類，用於管理請假審批流程：

public class HR
{
    public Manager GetManager()
    {
        TL tL = new TL("李四");
        PM pM = new PM("王五");
        CTO cTO = new CTO("趙六");
        tL.NextManager = pM;
        pM.NextManager = cTO;
        return tL;
    }
}

然後，再看看呼叫的地方：

static void Main(string[] args)
{
    ...

    HR hR = new HR();
    Manager manager = hR.GetManager();
    manager.HandleRequest(context);

    ...
}

又變得簡單了，並且也更合理了。不過整體上還是有點自欺欺人，因為新的HR類又面向實現程式設計，變得難以維護了，因此，還得改進，改進方法還是老套路，面向抽象程式設計，然後通過集合管理多個例項，具體程式碼如下：

public class HR
{
    private List<Manager> _managers = new List<Manager>();

    public void AddManager(Manager manager)
    {
        _managers.Add(manager);
    }

    public Manager GetManager()
    {
        Manager currentManager = null;
        for (int i = _managers.Count - 1; i >= 0; i--)
        {
            if (currentManager != null)
            {
                _managers[i].NextManager = currentManager;
            }

            currentManager = _managers[i];
        }

        return currentManager;
    }
}

這裡直接一步到位了，但是應該能看懂，不過，大家有沒有看出這是建造者模式呢？沒看出也沒關係，我們後面會再改進一次，畢竟HR沒面向抽象程式設計，光禿禿的看著也不舒服。但在此之前，我們先看看呼叫的地方：

static void Main(string[] args)
{
    ...

    HR hR = new HR();
    hR.AddManager(new TL("李四"));
    hR.AddManager(new PM("王五"));
    hR.AddManager(new CTO("趙六"));

    Manager manager = hR.GetManager();
    manager.HandleRequest(context);

    ...
}

看到這裡的朋友怕是要開罵了，這到底是想幹啥，封裝來封裝去，來來回回好幾次，最後還是回到了原點。但事實上，已經有了很大的不同，第一次，呼叫者對業務邏輯有了較深的耦合，例如呼叫者必須知道每個領導的審批權力；第二次，耦合度降低了，但還是需要知道呼叫鏈的關係，而第三次，也就是這一次，其它的都不用知道，只需要建立物件就可以了，而建立物件是無論如何都繞不開的。並且，我們經過一次次的改進，看似還是回到了原點，但實際上已經將變化一步步從程式內部拋到了程式的最外層，可以通過依賴注入進一步解耦了，我們不妨換成ASP.Net Core應用程式看看，同時我們再進行以此改造:

public interface IManagerBuilder
{
    void AddManager(Manager manager);

    Manager Build();
}

public class ManagerBuilder: IManagerBuilder
{
    private readonly List<Manager> _managers = new List<Manager>();

    public void AddManager(Manager manager)
    {
        _managers.Add(manager);
    }

    public Manager Build()
    {
       ...
    }
}

其實這次改造並沒有實質性的變化，僅僅是換了個名字並且加了個抽象的介面而已，目的是為了方便看出它確實是建造者模式。重點是如何使用它，先新增如下針對IServiceCollection的擴充套件方法。

 public static class ManagerServiceCollectionExtensions
 {
    public static IManagerBuilder AddManagers(this IServiceCollection services)
    {
        IManagerBuilder managerBuilder = new ManagerBuilder();
        managerBuilder.AddManager(new TL("李四"));
        managerBuilder.AddManager(new PM("王五"));
        managerBuilder.AddManager(new CTO("趙六"));
        services.AddSingleton(managerBuilder);
        return managerBuilder;
    }
}

然後在Startup中呼叫，程式碼如下所示：

public void ConfigureServices(IServiceCollection services)
{
    services.AddControllers();
    services.AddManagers();
}

好了，就是這麼簡單，接下來就可以在專案的任何地方通過依賴注入的方式使用了，當然，AddManagers(this IServiceCollection services)還有瑕疵，但是，這可以通過配置檔案或者讀取資料庫的方式解決，這裡就不再繼續深入下去了。

優缺點

優點

責任鏈模式最大的優點就是將請求和處理分離，請求者可以不用知道是誰處理的，處理者也可以不用知道請求的全貌，兩者解耦，提高系統的靈活性。

缺點

效能不高

既然責任鏈模式的核心是“鏈”，就說明每次請求都需要遍歷整個鏈條，這必然會帶來較大的效能損耗，不過事實上，責任鏈模式並非必須使用鏈條，我們知道資料結構中有陣列和連結串列兩種結構，而我們前面剛學過的觀察模式就和責任鏈模式就有類似的關係，觀察者模式中通過集合儲存所有的觀察者，然後遍歷集合，責任鏈模式也可以採用相同的手段，不過責任鏈模式採用集合儲存所有處理者之後，或許就變成觀察者模式了，但是這重要嗎？

除錯不方便

責任鏈模式採用了類似遞迴的方式，除錯的時候邏輯可能比較複雜。

總結

責任鏈模式通常可以用在含有流程的業務中，如工作流，流水線，請求流等，當然也可以將一個大的功能塊切分成若干小塊，然後通過責任鏈模式串聯起來，責任鏈模式常見於各種框架中，是程式碼重構的利器，不過由於其效能不高，邏輯相對複雜，並且如果責任劃分不清，很容易產生誤用，帶來的可能是災難，因此也需要慎重使用。況且，能通過責任鏈模式實現的場景往往也可以通過其它模式代替，如策略模式，狀態模式，觀察者模式等。另外，責任鏈模式的每個處理者也可以只處理請求的一部分，ASP.Net Core中的中介軟體就是典型例子，還有前面請假的例子，在有些公司，不管請多少天假，可能都需要所有領導逐級審批，所有領導都同意才算通過，只要有一個不同意就不通過，這依然是責任鏈模式。

責任鏈模式使用起來可以非常靈活，實現方式也不止一種，但很少單獨使用，更多時候還需要搭配其他模式一起使用，因此，要用好責任鏈模式也別忘了複習其它設計模式哦！

原始碼連結