設計模式-責任鏈模式-有解無憂

作為一個上班族，我們可能會經常聽到“管理流程混亂”，“職責邊界不清晰”等這樣或那樣的抱怨，這是當組織或系統發展壯大后，一件事由一個人或者一個部門無法獨立完成時，不得不面對的問題，就拿平時請假來說，試想如果是一個只有幾個人的小公司，很可能連請假條都不用寫，直接跟老板說一下就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中的中間件就是典型例子，還有前面請假的例子，在有些公司，不管請多少天假，可能都需要所有領導逐級審批，所有領導都同意才算通過，只要有一個不同意就不通過，這依然是責任鏈模式，

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

原始碼鏈接

轉載請註明出處，本文鏈接：https://www.uj5u.com/ruanti/287081.html

標籤：其他

上一篇：設計模式-責任鏈模式

下一篇：用java寫一個博客網站