前言 今天我們介紹的是責任鏈模式【Chain of Responsibility Pattern】。對於責任鏈模式理解起來還是比較容易的。例如在公司請假、三天以內部門經理批准即可，但是三到七天可能就需要總監批准了、七天以上需要副總裁批准。對於這麼一個需求最初的解決方案就是if-else語句判斷。但是 ...
前言
今天我們介紹的是責任鏈模式【Chain of Responsibility Pattern】。對於責任鏈模式理解起來還是比較容易的。例如在公司請假、三天以內部門經理批准即可，但是三到七天可能就需要總監批准了、七天以上需要副總裁批准。對於這麼一個需求最初的解決方案就是if-else語句判斷。但是 一旦請假的模式增加一種則需要對多重if-else進行修改，這就違背了開閉原則。這個時候就可以採用責任鏈模式來解決其問題。責任鏈模式為請求創建一個接收者對象的鏈。這種模式給予請求的類型，對請求的發送者和接收者進行解耦。
責任鏈模式介紹
一、來由
在軟體系統中，經常會有一個請求可能會被多個對象處理。但是每一次都是被一個對象處理。又不能確定是哪一個對象。如果顯示指定每一個對象。會對請求發送者和接收者造成緊耦合。那麼如何做到對請求的發送者和接收者進行解耦。並且在運行時自行決定處理請求的對象呢？
二、意圖
避免請求發送者與接收者耦合在一起，讓多個對象都有可能接收請求，將這些對象連接成一條鏈，並且沿著這條鏈傳遞請求，直到有對象處理它為止。
三、案例
四、責任鏈模式代碼示例
看上述案例圖，主要涉及到兩個部分：
抽象處理者：定義一個處理請求的介面
具體處理者：實現處理請求的介面、可以選擇是自己處理或者傳遞給下一個接收者。包含對下一個接收處理者的引用。
責任鏈模式的組成部分還是比較簡單的。我們看這麼一個案例，還是用戶結算時金額計算的案例。根據用戶的會員等級進行對應的折扣結算。普通用戶全額計算、普通會員95折計算、黃金會員9折計算、鑽石會員7折計算：
我們首先看看不使用責任鏈模式如何處理：
namespace ChainofResponsibility_Pattern
{
class Program
{
static void Main(string[] args)
{
decimal Money = 200M;
var memberType = MemberType.GoldMember;
//普通會員，95折計算
if (memberType == MemberType.Member)
{
Console.WriteLine($"普通會員，95折計算,最後金額為{Money * 0.95M}");
}
//黃金會員，9折計算
else if (memberType == MemberType.GoldMember)
{
Console.WriteLine($"黃金會員，9折計算,最後金額為{Money * 0.9M}");
}
//鑽石會員，7折計算
else if (memberType == MemberType.DiamondsMember)
{
Console.WriteLine($"鑽石會員，7折計算,最後金額為{Money * 0.7M}");
}
//無會員，全額計算
else
{
Console.WriteLine($"無會員，全額計算,最後金額為{Money}");
}
}
public enum MemberType
{
[Description("無會員")]
NoMember = 1,
[Description("普通會員")]
Member = 2,
[Description("黃金會員")]
GoldMember = 3,
[Description("鑽石會員")]
DiamondsMember = 4
}
}
}
這裡我們可以看到我們使用了多個if條件判斷完成的此需求（或者switch語句）。這裡我們增加一種會員方式或者優惠折扣都是直接對條件語句進行修改的。或者某個會員的折扣進行了修改都需要對條件進行修改。這裡請求的發送者和接收者具有緊耦合。並且多個if條件加在一起，不易於判斷及理解。
我們再看看使用責任鏈模式：
namespace ChainofResponsibility_Pattern { public enum MemberType { [Description("無會員")] NoMember=1, [Description("普通會員")] Member =2, [Description("黃金會員")] GoldMember =3, [Description("鑽石會員")] DiamondsMember =4 } class ChainofResponsibilityPattern { } /// <summary> /// 結算請求 /// </summary> public class SettlementRequest { /// <summary> /// 金額 /// </summary> public decimal _money; /// <summary> /// 會員類型 /// </summary> public MemberType _memberType; public SettlementRequest(decimal money,MemberType memberType) { this._money = money; this._memberType = memberType; } } /// <summary> /// 結算抽象處理 /// </summary> public abstract class SettlementHandler { /// <summary> /// 下一位接收處理者 /// </summary> public SettlementHandler nextHandler; public abstract void Settlement(SettlementRequest settlementRequest); } /// <summary> /// 無會員接收者 /// </summary> public class NoMemberHandler : SettlementHandler { public override void Settlement(SettlementRequest settlementRequest) { if (settlementRequest._memberType==MemberType.NoMember) { Console.WriteLine($"無會員，不進行折扣計算。最後金額為{settlementRequest._money}"); } else { nextHandler.Settlement(settlementRequest); } } } /// <summary> /// 普通會員接收處理者 /// </summary> public class MemberHandler : SettlementHandler { public override void Settlement(SettlementRequest settlementRequest) { if (settlementRequest._memberType == MemberType.Member) { Console.WriteLine($"普通會員，95折計算。最後金額為{settlementRequest._money*0.9M}"); } else { nextHandler.Settlement(settlementRequest); } } } /// <summary> /// 黃金會員接收處理者 /// </summary> public class GoldMemberHandler : SettlementHandler { public override void Settlement(SettlementRequest settlementRequest) { if (settlementRequest._memberType == MemberType.GoldMember) { Console.WriteLine($"黃金會員，9折計算。最後金額為{settlementRequest._money*0.9M}"); } else { nextHandler.Settlement(settlementRequest); } } } /// <summary> /// 鑽石會員接收處理者 /// </summary> public class DiamondsMemberHandler : SettlementHandler { public override void Settlement(SettlementRequest settlementRequest) { if (settlementRequest._memberType == MemberType.DiamondsMember) { Console.WriteLine($"鑽石會員，7折計算。最後金額為{settlementRequest._money*0.7M}"); } else { nextHandler.Settlement(settlementRequest); } } } }
namespace ChainofResponsibility_Pattern { class Program { static void Main(string[] args) { ///設置請求 SettlementRequest settlementRequest = new SettlementRequest(200, MemberType.GoldMember); ///初始化具體處理 SettlementHandler NoMember = new NoMemberHandler(); SettlementHandler Member = new MemberHandler(); SettlementHandler GoldMember = new GoldMemberHandler(); SettlementHandler DiamondsMember = new DiamondsMemberHandler(); ///設置責任鏈 NoMember.nextHandler = Member; Member.nextHandler = GoldMember; GoldMember.nextHandler = DiamondsMember; ///處理請求 NoMember.Settlement(settlementRequest); } } }
這裡我們將會員判斷及計算細化到了不同的類中。每一個類都僅針對他自己的會員折扣進行計算。我們增加會員模式也僅需要增加一個具體處理類並且重建責任鏈即可。如果修改某個會員的對應折扣也僅修改對應的類即可。我們看下麵的運行結果和上面的也是一樣的。
使用場景及優缺點
一、使用場景
1、有多個對象處理同一個請求，具體哪一個對象處理在運行時自行確定
2、在不明白具體接收者的情況下，向多個對象中的一個提交請求
3、代碼塊中存在多個if-else語句的情況下，可以考慮使用責任鏈模式進行重構
4、一個系統的審批需要多個對象才能完成處理。例如請假系統或者採購模塊。
二、優點
1、降低請求發送者和接收者之間的耦合度
2、簡化了對象、使對象不清除鏈的結構
3、增加了對象指派職責的靈活度、增強了可擴展性
4、將多個條件語句進行分散到各個具體處理類中，增加代碼的可閱讀性。使代碼更加清晰，責任更明確
三、缺點
1、在未找到請求接收者之前會對多有對象執行一遍，如果責任鏈過長會對性能造成一定影響
2、可能導致某一個請求不被處理
3、可能不太容易進行錯誤排查
4、容易造成迴圈調用
總結
責任鏈模式主要降低了請求發送者和接收者之間的耦合度。使得多個對象都有機會處理某一個請求。在請假系統中可能需要多個人物對請假進行審批。採購系統中可能需要不同高度的人進行審批。一個請求可能由多個對象處理，但是不清楚具體接收者對象。所以將對象連成一條鏈子，使請求沿著這條鏈子傳遞下去。直到被處理為止、這就是責任鏈模式。
即使受傷了，也要抬起頭微笑著說，今天天氣真好。
歡迎大家掃描下方二維碼，和我一起踏上設計模式的闖關之路吧!
