1. 程式人生 > >通俗易懂設計模式解析——責任鏈模式

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

前言

  今天我們介紹的是責任鏈模式【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、容易造成迴圈呼叫

總結

  責任鏈模式主要降低了請求傳送者和接收者之間的耦合度。使得多個物件都有機會處理某一個請求。在請假系統中可能需要多個人物對請假進行審批。採購系統中可能需要不同高度的人進行審批。一個請求可能由多個物件處理,但是不清楚具體接收者物件。所以將物件連成一條鏈子,使請求沿著這條鏈子傳遞下去。直到被處理為止、這就是責任鏈模式。


    即使受傷了,也要擡起頭微笑著說,今天天氣真好。

    C#設計模式系列目錄

      歡迎大家掃描下方二維碼,和我一起踏上設計模式的闖關之路吧!