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