通俗易懂設計模式解析——責任鏈模式

前言

　　今天咱們介紹的是責任鏈模式【Chain of Responsibility Pattern】。對於責任鏈模式理解起來仍是比較容易的。例如在公司請假、三天之內部門經理批准便可，可是三到七天可能就須要總監批准了、七天以上須要副總裁批准。對於這麼一個需求最初的解決方案就是if-else語句判斷。可是 一旦請假的模式增長一種則須要對多重if-else進行修改，這就違背了開閉原則。這個時候就能夠採用責任鏈模式來解決其問題。責任鏈模式爲請求建立一個接收者對象的鏈。這種模式給予請求的類型，對請求的發送者和接收者進行解耦。

責任鏈模式介紹

1、來由

　　在軟件系統中，常常會有一個請求可能會被多個對象處理。可是每一次都是被一個對象處理。又不能肯定是哪個對象。若是顯示指定每個對象。會對請求發送者和接收者形成緊耦合。那麼如何作到對請求的發送者和接收者進行解耦。而且在運行時自行決定處理請求的對象呢？

2、意圖

　　避免請求發送者與接收者耦合在一塊兒，讓多個對象都有可能接收請求，將這些對象鏈接成一條鏈，而且沿着這條鏈傳遞請求，直到有對象處理它爲止。

3、案例

4、責任鏈模式代碼示例

看上述案例圖，主要涉及到兩個部分：

　　抽象處理者：定義一個處理請求的接口

　　具體處理者：實現處理請求的接口、能夠選擇是本身處理或者傳遞給下一個接收者。包含對下一個接收處理者的引用。

責任鏈模式的組成部分仍是比較簡單的。咱們看這麼一個案例，仍是用戶結算時金額計算的案例。根據用戶的會員等級進行對應的折扣結算。普通用戶全額計算、普通會員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、使用場景

一、有多個對象處理同一個請求，具體哪個對象處理在運行時自行肯定

二、在不明白具體接收者的狀況下，向多個對象中的一個提交請求

三、代碼塊中存在多個if-else語句的狀況下，能夠考慮使用責任鏈模式進行重構

四、一個系統的審批須要多個對象才能完成處理。例如請假系統或者採購模塊。

2、優勢

一、下降請求發送者和接收者之間的耦合度

二、簡化了對象、使對象不清除鏈的結構

三、增長了對象指派職責的靈活度、加強了可擴展性

四、將多個條件語句進行分散到各個具體處理類中，增長代碼的可閱讀性。使代碼更加清晰，責任更明確

3、缺點

一、在未找到請求接收者以前會對多有對象執行一遍，若是責任鏈過長會對性能形成必定影響

二、可能致使某一個請求不被處理

三、可能不太容易進行錯誤排查

四、容易形成循環調用

總結

　　責任鏈模式主要下降了請求發送者和接收者之間的耦合度。使得多個對象都有機會處理某一個請求。在請假系統中可能須要多我的物對請假進行審批。採購系統中可能須要不一樣高度的人進行審批。一個請求可能由多個對象處理，可是不清楚具體接收者對象。因此將對象連成一條鏈子，使請求沿着這條鏈子傳遞下去。直到被處理爲止、這就是責任鏈模式。

　　即便受傷了，也要擡起頭微笑着說，今每天氣真好。