C#設計模式學習筆記:(20)職責鏈模式

来源:https://www.cnblogs.com/atomy/archive/2020/02/21/12341548.html
-Advertisement-
Play Games

本筆記摘抄自:https://www.cnblogs.com/PatrickLiu/p/8109100.html,記錄一下學習過程以備後續查用。 一、引言 今天我們要講行為型設計模式的第八個模式--職責鏈模式。讓我們看看現實生活中某公司採購流程的例子吧,理解起來可能更容易。某公司的規章制度 規定,採 ...


    本筆記摘抄自:https://www.cnblogs.com/PatrickLiu/p/8109100.html,記錄一下學習過程以備後續查用。

    一、引言

    今天我們要講行為型設計模式的第八個模式--職責鏈模式。讓我們看看現實生活中某公司採購流程的例子吧,理解起來可能更容易。某公司的規章制度

規定,採購原材料的總價在5萬之內,只需要經理級別的人批准即可;採購總價大於5萬小於10萬的則需要財務經理進行批准;總價大於10萬小於30萬的

需要總經理批准;總價大於30萬的則需要通過董事會會議討論決定。對於這樣一個需求,最直接的方法就是設計一個方法,該方法接受的參數是採購的總

價,然後在這個方法內對價格進行判斷,然後針對不同的條件交給不同級別的角色去處理。如果情況就是這樣,不變了,這樣做很好,沒問題。如果我們

又有新的條件要增加該怎麼辦呢?我們不得不去修改原來設計的方法來再添加一個條件判斷,讓本已多重的if-else判斷語句更多了,這樣的設計顯然違背

了“開閉原則”。這時候,我們可以採用職責鏈模式來解決這樣的問題。

    二、職責鏈模式介紹

    職責鏈模式:英文名稱--Chain of Responsibility Pattern;分類--行為型。

    2.1、動機(Motivate)

    在軟體構建過程中,一個請求可能被多個對象處理,但是每個請求在運行時只能有一個接受者,如果顯示指定,將必不可少地帶來請求發送者與接受者

的緊耦合。如何使請求的發送者不需要指定具體的接受者,讓請求的接受者自己在運行時決定來處理請求,從而使兩者解耦。

    2.2、意圖(Intent)

    避免請求發送者與接收者耦合在一起,讓多個對象都有可能接受請求,將這些對象連接成一條鏈,並且沿著這條鏈傳遞請求,知道有對象處理它為止。

——《設計模式》GoF

    2.3、結構圖(Structure)

    2.4、模式的組成

    可以看出,在職責鏈模式的結構圖有以下角色:

    1)抽象處理者角色(Handler):抽象處理者定義了一個處理請求的介面,它一般設計為抽象類。由於不同的具體處理者處理請求的方式不同,因此在

其中定義了抽象請求處理方法。因為每一個處理者的下家還是一個處理者,因此在抽象處理者中定義了一個自類型的對象,作為其對下家的引用。通過該

引用,處理者可以連成一條鏈。

    2)具體處理者角色(ConcreteHandler):具體處理者是抽象處理者的子類,它可以處理用戶請求。在具體處理者類中實現了抽象處理者中定義的抽象

處理方法,在處理請求之前需要進行判斷,看是否有相應的處理許可權?如果可以處理請求就處理它,否則將請求轉發給後繼者。在具體處理者中可以訪問

鏈中下一個對象,以便請求的轉發。

    2.5、職責鏈模式的具體實現

    在現實生活中,職責鏈模式的例子也是很多的,例如:公司的請假流程就是一個很好的職責鏈模式的例子。如果請假半天,只要告訴本部門經理就可以

了;如果請假7天或者以上必須人事總監批准;如果請假15天以上,那就要經過總裁批准了。還有類似的例子就是採購的流程,其流程也是職責鏈模式很

好的體現,採購金額的不同,需要批准的人員也不同。下麵就以採購的實例來說明職責鏈模式,實現代碼如下:

    class Program
    {
        /// <summary>
        /// 採購請求
        /// </summary>
        public sealed class PurchaseRequest
        {
            //金額
            public double Amount { get; set; }

            //產品名字
            public string ProductName { get; set; }

            public PurchaseRequest(double amount, string productName)
            {
                Amount = amount;
                ProductName = productName;
            }
        }

        /// <summary>
        /// 抽象審批人--相當於“抽象處理者角色”
        /// </summary>
        public abstract class Approver
        {
            //下一位審批人,由此形成一條鏈。
            public Approver NextApprover { get; set; }

            //審批人的名稱
            public string Name { get; set; }

            public Approver(string name)
            {
                Name = name;
            }

            //處理請求
            public abstract void ProcessRequest(PurchaseRequest request);
        }

        /// <summary>
        /// 部門經理--相當於“具體處理者角色”
        /// </summary>
        public sealed class Manager : Approver
        {
            public Manager(string name) : base(name) { }

            public override void ProcessRequest(PurchaseRequest request)
            {
                if (request.Amount <= 10000.0)
                {
                    Console.WriteLine("部門經理{0}批准了對原材料{1}的採購計劃。", Name, request.ProductName);
                }
                else if (NextApprover != null)
                {
                    Console.WriteLine("部門經理{0}批准了對原材料{1}的採購計劃。", Name, request.ProductName);
                    NextApprover.ProcessRequest(request);
                }
            }
        }

        /// <summary>
        /// 財務經理--相當於“具體處理者角色”
        /// </summary>
        public sealed class FinancialManager : Approver
        {
            public FinancialManager(string name) : base(name) { }

            public override void ProcessRequest(PurchaseRequest request)
            {
                if (request.Amount > 10000.0 && request.Amount <= 50000.0)
                {
                    Console.WriteLine("財務經理{0}批准了對原材料{1}的採購計劃。", Name, request.ProductName);
                }
                else if (NextApprover != null)
                {
                    Console.WriteLine("財務經理{0}批准了對原材料{1}的採購計劃。", Name, request.ProductName);
                    NextApprover.ProcessRequest(request);
                }
            }
        }

        /// <summary>
        /// 總裁--相當於“具體處理者角色”
        /// </summary>
        public sealed class CEO : Approver
        {
            public CEO(string name) : base(name) { }

            public override void ProcessRequest(PurchaseRequest request)
            {
                if (request.Amount > 50000.0 && request.Amount < 300000.0)
                {
                    Console.WriteLine("總裁{0}批准了對原材料{1}的採購計劃。", Name, request.ProductName);
                }
                else
                {
                    Console.WriteLine("這個採購計劃的金額比較大,需要董事會會議討論才能決定。");
                }
            }
        }

        static void Main(string[] args)
        {
            #region 職責鏈模式
            PurchaseRequest requestDao = new PurchaseRequest(9000.0, "單刀5把");
            PurchaseRequest requestHuaJi = new PurchaseRequest(40000.0, "10把方天畫戟");
            PurchaseRequest requestJian = new PurchaseRequest(90000.0, "5把金絲龍鱗閃電劈");

            Approver manager = new Manager("黃飛鴻");
            Approver financial = new FinancialManager("黃麒英");
            Approver ceo = new CEO("十三姨");

            //設置職責鏈
            manager.NextApprover = financial;
            financial.NextApprover = ceo;

            //處理請求
            manager.ProcessRequest(requestDao);
            Console.WriteLine();
            manager.ProcessRequest(requestHuaJi);
            Console.WriteLine();
            manager.ProcessRequest(requestJian);

            Console.ReadLine();
            #endregion
        }
    }
View Code

    運行結果如下:

    三、職責鏈模式的實現要點

    Chain of Responsibility模式的應用場合在於“一個請求可能有多個接受者,但是最後真正的接受者只有一個”,只有這時候請求發送者與接受者的耦合才

有可能出現“變化脆弱”的癥狀,職責鏈的目的就是將二者解耦,從而更好地應對變化。

    應用了Chain of Responsibility模式後,對象的職責分派將更具靈活性,我們可以在運行時動態添加/修改請求的處理職責。

    當我們要新增一個Handler處理請求,就不需再改原來的代碼了,遵從了開放封閉原則。這樣我們的程式就更賦予變化,更有變化的抵抗力。Handler類

本身繼承自BaseHandler類型,又包含了一個BaseHandler類型的對象,這點類似Decorator模式。

    如果請求傳遞到職責鏈的末尾仍得不到處理,應該有一個合理的預設機制,這也是每一個接受對象的責任,而不是發出請求的對象的責任。

    3.1、職責鏈模式的主要優點

    1)降低耦合度:職責鏈模式使得一個對象無需知道是其它哪一個對象處理其請求,對象僅需知道該請求會被處理即可。接受者和發送者都沒有對方的明

確信息,且鏈中的對象不需要知道鏈的結構,有客戶端負責鏈的創建。

    2)可簡化對象的相互連接:接受者對象僅需維持一個指向其後繼者的引用,而不需維持它對所有的候選處理者的引用。

    3)增強給對象指派職責的靈活性:在給對象分派職責時,職責鏈可以給我們帶來更多的靈活性。可以通過在運行時對該連進行動態的增加或修改處理一

個請求的職責。

    4)增加新的請求處理類很方便:在系統中增加一個新的請求處理者無需修改原有系統的代碼,只需要在客戶端重新建鏈即可,從這一點看來是符合開閉

原則的。

 3.2、職責鏈模式的主要缺點

    1)在找到正確的處理對象之前,所有的條件判定都要執行一遍,當責任鏈過長時,可能會引起性能的問題。

    2)可能導致某個請求不被處理。

    3)客戶端需要組裝這個鏈條,耦合了客戶端和鏈條的組成結構,可以把這個在客戶端的組合動作提到外面,通過配置來做會更好點。

    3.3、在下麵的情況下可以考慮使用職責鏈模式

    1)一個系統的審批需要多個對象才能完成處理的情況下,例如請假系統等。

    2)代碼中存在多個if-else語句的情況下,此時可以考慮使用責任鏈模式來對代碼進行重構。

    3)有多個對象可以處理同一個請求,具體哪個對象處理該請求在運行時刻自動確定。客戶端只需將請求提交到鏈上,無須關心請求的處理對象是誰以及

它是如何處理的。

    4)不明確指定接受者的情況下,向多個對象中的一個提交一個請求。請求的發送者與請求者解耦,請求將沿著鏈進行傳遞,尋求響應的處理者。

    5)可動態指定一組對象處理請求。客戶端可以動態創建職責鏈來處理請求,還可以動態改變鏈中處理者之間的先後次序。

    四、.NET中職責鏈模式的實現

    這個模式在.Net框架中的實現不多,個人覺得這個模式的使用場景更多的是在業務系統中才會有更大的用處。這種模式在處理UI的消息時很常用,但實際

上Windows消息迴圈還是硬編碼的結構,主要是效率上的考慮。Windows消息迴圈是哪個對象有一個請求,則直接將請求送至處理函數的地址。如果鏈條上

的對象多了,而真正處理的函數在鏈條後部分,效率會很低下。因此我們在使用這種模式的時候更適合業務流程,即對性能要求不是特別高的情況更加常用。

    五、總結

    這個模式也是為瞭解耦,解耦請求的發送者和接受者,當有新的需求的時候更容易變化,讓我們的代碼更符合面向對象OO的設計。


您的分享是我們最大的動力!

-Advertisement-
Play Games
更多相關文章
  • 本文是根據慕課網Jason老師的課程進行的PHP面試知識點總結和升華,如有侵權請聯繫我進行刪除,email:[email protected] 在面試中,考官往往喜歡基礎扎實的面試者,而函數相關的考點,往往是大家容易忽視的一個點,今天冷月就來幫各位小伙伴們梳理一下,在面試中函數相關的註意點。 回顧真 ...
  • 封裝的Redis隊列 MyRedisQueue.py 接收端 發送端 ...
  • 1. 註釋註釋 是任何存在於 # 號右側的文字,其主要用作寫給程式讀者看的筆記。 2. 字面常量一個字面常量(Literal Constants)的例子是諸如 5、1.23 這樣的數字,或者是如 這是一串文本 或 This is a string 這樣的文本。 &每天都有程式員定時講解Python技 ...
  • 在家辦公,下班繼續看點東西,不廢話,繼續看MVC的路由。 asp.net核心mvc的路由是建立在asp.net核心的路由之上的。通過終結點載入路由中間件的配置方式在此不細說了,(DOTNET Core MVC(二)已經說明)。在看一下其他的載入方式: app.UseMvc(routes => { / ...
  • 前言 這兩天面試了一個物聯網公司高級研發,面試題是下麵這樣子 公司領導,部門主管,小組組長,組成員4級,假如有個 疫情預警,先通知組人員(對個人,主要有一個處理就算處理了) 如果3分鐘沒處理,就往組長髮簡訊,如果組長3分鐘沒處理就往上級推送。一級一級的。 要求單程式併發至少支持1000tps預警事件 ...
  • WPF提供了可應用於任何元素的可視化效果。效果的目標是提供一種簡單的聲明式方法,從而改進文本、圖像、按鈕以及其他控制項的外觀。不是編寫自己的繪圖代碼,而是使用某個繼承自Effect的類(位於System.Windows.Media.Effects名稱空間中)以立即獲得諸如模糊、輝光以及陰影等效果。 下 ...
  • 一談到如何在.Net中進行對象映射,可能大部分同學都會脫口而出:“使用AutoMapper!”。 是的,AutoMapper 是一個非常成熟的對象映射器。截至到寫這篇文章,您能在Nuget上下載到的AutoMapper包的版本為:v9.0.0,而對應的 Github 的 star 已經高達7K。然後... ...
  • 通過前面的文章的學習,我們已經有實現了使用ABP提供的WebAPI方式+EasyUI來實現增刪改查的功能。之前我們把一些基本的信息已經完成了,如貨物信息,供應商信息。有了前面的基礎信息,我們可以實現入庫管理功能。從本章開始我們來學習一個入庫單功能,這個將會涉及DataGrid的主從功能。 一... ...
一周排行
    -Advertisement-
    Play Games
  • Timer是什麼 Timer 是一種用於創建定期粒度行為的機制。 與標準的 .NET System.Threading.Timer 類相似,Orleans 的 Timer 允許在一段時間後執行特定的操作,或者在特定的時間間隔內重覆執行操作。 它在分散式系統中具有重要作用,特別是在處理需要周期性執行的 ...
  • 前言 相信很多做WPF開發的小伙伴都遇到過表格類的需求,雖然現有的Grid控制項也能實現,但是使用起來的體驗感並不好,比如要實現一個Excel中的表格效果,估計你能想到的第一個方法就是套Border控制項,用這種方法你需要控制每個Border的邊框,並且在一堆Bordr中找到Grid.Row,Grid. ...
  • .NET C#程式啟動閃退,目錄導致的問題 這是第2次踩這個坑了,很小的編程細節,容易忽略,所以寫個博客,分享給大家。 1.第一次坑:是windows 系統把程式運行成服務,找不到配置文件,原因是以服務運行它的工作目錄是在C:\Windows\System32 2.本次坑:WPF桌面程式通過註冊表設 ...
  • 在分散式系統中,數據的持久化是至關重要的一環。 Orleans 7 引入了強大的持久化功能,使得在分散式環境下管理數據變得更加輕鬆和可靠。 本文將介紹什麼是 Orleans 7 的持久化,如何設置它以及相應的代碼示例。 什麼是 Orleans 7 的持久化? Orleans 7 的持久化是指將 Or ...
  • 前言 .NET Feature Management 是一個用於管理應用程式功能的庫,它可以幫助開發人員在應用程式中輕鬆地添加、移除和管理功能。使用 Feature Management,開發人員可以根據不同用戶、環境或其他條件來動態地控制應用程式中的功能。這使得開發人員可以更靈活地管理應用程式的功 ...
  • 在 WPF 應用程式中,拖放操作是實現用戶交互的重要組成部分。通過拖放操作,用戶可以輕鬆地將數據從一個位置移動到另一個位置,或者將控制項從一個容器移動到另一個容器。然而,WPF 中預設的拖放操作可能並不是那麼好用。為瞭解決這個問題,我們可以自定義一個 Panel 來實現更簡單的拖拽操作。 自定義 Pa ...
  • 在實際使用中,由於涉及到不同編程語言之間互相調用,導致C++ 中的OpenCV與C#中的OpenCvSharp 圖像數據在不同編程語言之間難以有效傳遞。在本文中我們將結合OpenCvSharp源碼實現原理,探究兩種數據之間的通信方式。 ...
  • 一、前言 這是一篇搭建許可權管理系統的系列文章。 隨著網路的發展,信息安全對應任何企業來說都越發的重要,而本系列文章將和大家一起一步一步搭建一個全新的許可權管理系統。 說明:由於搭建一個全新的項目過於繁瑣,所有作者將挑選核心代碼和核心思路進行分享。 二、技術選擇 三、開始設計 1、自主搭建vue前端和. ...
  • Csharper中的表達式樹 這節課來瞭解一下表示式樹是什麼? 在C#中,表達式樹是一種數據結構,它可以表示一些代碼塊,如Lambda表達式或查詢表達式。表達式樹使你能夠查看和操作數據,就像你可以查看和操作代碼一樣。它們通常用於創建動態查詢和解析表達式。 一、認識表達式樹 為什麼要這樣說?它和委托有 ...
  • 在使用Django等框架來操作MySQL時,實際上底層還是通過Python來操作的,首先需要安裝一個驅動程式,在Python3中,驅動程式有多種選擇,比如有pymysql以及mysqlclient等。使用pip命令安裝mysqlclient失敗應如何解決? 安裝的python版本說明 機器同時安裝了 ...