20. 設計模式-責任鏈模式

時間 2021-06-13

標籤 git 程序員 github 算法數據庫編程設計模式數組數據結構框架欄目 Git 简体版

原文原文鏈接

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

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

示例

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

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中的中間件就是典型例子，還有前面請假的例子，在有些公司，無論請多少天假，可能都須要全部領導逐級審批，全部領導都贊成纔算經過，只要有一個不一樣意就不經過，這依然是責任鏈模式。

責任鏈模式使用起來能夠很是靈活，實現方式也不止一種，但不多單獨使用，更多時候還須要搭配其餘模式一塊兒使用，所以，要用好責任鏈模式也別忘了複習其它設計模式哦！

源碼連接