設計模式-責任鏈模式

煮詩君發表於2021-06-13

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

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

原始碼連結

相關文章