實例講解C#中的職責(zé)鏈模式
大家好，歡迎來到老胡的博客，今天我們繼續(xù)了解設(shè)計模式中的職責(zé)鏈模式，這是一個比較簡單的模式。跟往常一樣，我們還是從一個真實世界的例子入手，這樣大家也對這個模式的應(yīng)用場景有更深刻的理解。
一個真實的栗子
作為上班族，相信大家對請假都不陌生，每個公司都有自己請假的流程，稍微講究點的公司還會有細致的規(guī)定，比如，3天以內(nèi)的假期，小組長有權(quán)力批準，3天以上的假期就要找更高級別的領(lǐng)導(dǎo)批準。這種制度就是典型的權(quán)力越大職責(zé)越大——畢竟，批長假的職責(zé)只在高級主管那里存在。
除了規(guī)定出這樣細致的要求之外，大部分公司還有用軟件實現(xiàn)了請假流程，當請假人員提出請假申請的時候，會依據(jù)請假天數(shù)，轉(zhuǎn)發(fā)給具有權(quán)限的人員審批，讓我們看看這個系統(tǒng)的代碼實現(xiàn)吧。
請假系統(tǒng)實現(xiàn)
在這個系統(tǒng)中，我們假定：
- 小組長可以審批3天以內(nèi)的請假請求
- 部門經(jīng)理可以審批5天以內(nèi)的請假請求
- 10天以內(nèi)的請假請求只有老板才能審批
- 我們同時假定，這個公司的管理層非常人性化，請假都能得到批準，除非大于10天，因為這種情況沒人可以審批
請假申請
這是最簡單的類，封裝了請假天數(shù)和請假申請人
class VacationRequest
{
public int DayNum { get; set; }
public string RequesterName { get; set; }
}
假期審批者
首先創(chuàng)建一個抽象類，假期審批者，封裝假期審批的基本邏輯，即，如果當前人員有權(quán)限審批當前假期申請，就處理
abstract class VacationApprover
{
protected VacationApprover(int dayCanHandle)
{
DayCanHandle = dayCanHandle;
}
public int DayCanHandle { get; protected set; }
public void HandleVacationRequest(VacationRequest request)
{
if (request.DayNum <= DayCanHandle)
{
DoHandleVacationRequest(request);
}
}
protected abstract void DoHandleVacationRequest(VacationRequest request);
}
當然，抽象類只需要確定算法骨架，限定只有當前人員能處理這個請求的時候，才進行審批工作，至于具體的審批實現(xiàn)，留給子類自己去覆蓋，這種在父類固定算法骨架，暴露部分覆蓋點給子類的做法，就是之前我們提到過的TemplateMethod模式
具體假期審批者
小組長，部門經(jīng)理，老板，都在這里創(chuàng)建，他們分別處理能審批3、5、10天的請假申請
class TeamLeader : VacationApprover
{
private const int DAY_CAN_HANDLE_TEAMLEADER = 3;
public TeamLeader() : base(DAY_CAN_HANDLE_TEAMLEADER) { }
protected override void DoHandleVacationRequest(VacationRequest request)
{
Console.WriteLine("Now team leader handle this request");
Console.WriteLine("Team leader accept this request");
}
}
class DepartmentLeader : VacationApprover
{
private const int DAY_CAN_HANDLE_DEPARTMENTLEADER = 5;
public DepartmentLeader() : base(DAY_CAN_HANDLE_DEPARTMENTLEADER) { }
protected override void DoHandleVacationRequest(VacationRequest request)
{
Console.WriteLine("Now department leader handle this request");
Console.WriteLine("Department leader accept this request");
}
}
class Boss : VacationApprover
{
private const int DAY_CAN_HANDLE_BOSS = 10;
public Boss() : base(DAY_CAN_HANDLE_BOSS) { }
protected override void DoHandleVacationRequest(VacationRequest request)
{
Console.WriteLine("Now boss handle this request");
Console.WriteLine("Boss accept this request");
}
}
請假審批系統(tǒng)
請假審批系統(tǒng)提供統(tǒng)一請假申請接口，內(nèi)部通過請假天數(shù)決定哪個審批者參與審批
class VacationApproveSystem
{
private VacationApprover teamLeader = new TeamLeader();
private VacationApprover departmentLeader = new DepartmentLeader();
private VacationApprover boss = new Boss();
public void HandleVacationRequest(VacationRequest request)
{
Console.WriteLine("Now handle {0}'s {1} days' vacation request", request.RequesterName, request.DayNum);
if (request.DayNum <= teamLeader.DayCanHandle)
{
teamLeader.HandleVacationRequest(request);
}
else if (request.DayNum <= departmentLeader.DayCanHandle)
{
departmentLeader.HandleVacationRequest(request);
}
else if (request.DayNum <= boss.DayCanHandle)
{
boss.HandleVacationRequest(request);
}
else
{
Console.WriteLine("Cannot handle this request after all");
}
}
}
測試代碼
class Program
{
static void Main(string[] args)
{
VacationApproveSystem system = new VacationApproveSystem();
system.HandleVacationRequest(new VacationRequest() { DayNum = 5, RequesterName = "laohu" });
system.HandleVacationRequest(new VacationRequest() { DayNum = 10, RequesterName = "laohu" });
system.HandleVacationRequest(new VacationRequest() { DayNum = 12, RequesterName = "laohu" });
}
}
結(jié)果顯示
一切都是正常的，當5天時，部門經(jīng)理審批，10天時，老板審批，大于10天無人能批。 Good job。
回頭看看
實現(xiàn)了第一版代碼之后，我們再回過頭看看，雖然代碼功能無誤，但是VacationApproveSystem似乎承擔了過多的職責(zé)，它不但需要提供統(tǒng)一的請假審批接口給最終用戶，它同時還需要知道每個請假審批者能審批的請假天數(shù)并在內(nèi)部實現(xiàn)請假請求轉(zhuǎn)發(fā)給不同審批者的邏輯。這樣既違反了迪米特法則——它知道的太多了，也違反了開閉原則——如果任何一個審批者修改了自身能審批的請假天數(shù)，這個類都會被波及，最后，它還違反了單一職責(zé)——一個類只能有一個引起變化的原因。
有鑒于此，我們這版代碼只能算湊合用，但遠遠談不上結(jié)構(gòu)良好，老老實實地重構(gòu)代碼吧，下面請出我們今天的主角。
職責(zé)鏈模式
解耦具體對象和請求，使得多個對象都有機會處理請求。將對象連成一條鏈，沿著鏈傳遞請求直到有對象處理它
乍一聽有點生澀，翻譯一下就是
- 解耦具體對象和請求——不要預(yù)先指定哪個對象來處理此請求（因為很多時候并不知道）
- 使多個對象都有機會——有一眾候選對象，具體使用哪個對象是在運行時決定的
- 連成鏈傳遞請求——像鏈表一樣，要在對象中體現(xiàn)出對象之間的鏈關(guān)系，而不要通過其他類以if..else的方式實現(xiàn)
所以，這么看來這個模式和我們的例子簡直是絕配，我們已經(jīng)做了大部分的工作了，現(xiàn)在剩下的就只是修改審批者，讓審批者能鏈起來
代碼重構(gòu)
修改請假審批基類
最重要的改動，就是修改基類，讓對象能鏈起來，在VacationApprover中添加一個后繼節(jié)點和一個設(shè)置后繼節(jié)點的方法。同時在基類的審批方法中，完成請求傳遞，即，如果請假申請超過了當前審批人的能力范圍，則轉(zhuǎn)發(fā)至后繼節(jié)點。修改后的類如下
abstract class VacationApprover
{
private VacationApprover nextVacationApprover = null;
public void SetNextVacationApprover(VacationApprover approver)
{
nextVacationApprover = approver;
}
protected VacationApprover(int dayCanHandle)
{
DayCanHandle = dayCanHandle;
}
public int DayCanHandle { get; protected set; }
public void HandleVacationRequest(VacationRequest request)
{
if (request.DayNum <= DayCanHandle)
{
DoHandleVacationRequest(request);
}
else
{
if(nextVacationApprover != null)
{
nextVacationApprover.HandleVacationRequest(request);
}
else
{
Console.WriteLine("Cannot handle this request after all");
}
}
}
protected abstract void DoHandleVacationRequest(VacationRequest request);
}
修改請假審批系統(tǒng)
基類重構(gòu)結(jié)束之后，請假審批系統(tǒng)就可以瘦身了，刪除了所有判斷邏輯，僅僅在構(gòu)造函數(shù)里面完成鏈組建的工作，接著一鍵調(diào)用，齊活。
class VacationApproveSystem
{
private VacationApprover teamLeader = new TeamLeader();
private VacationApprover departmentLeader = new DepartmentLeader();
private VacationApprover boss = new Boss();
public VacationApproveSystem()
{
teamLeader.SetNextVacationApprover(departmentLeader);
departmentLeader.SetNextVacationApprover(boss);
}
public void HandleVacationRequest(VacationRequest request)
{
Console.WriteLine("Now handle {0}'s {1} days' vacation request", request.RequesterName, request.DayNum);
teamLeader.HandleVacationRequest(request);
}
}
測試
其他請假審批子類和測試客戶端都不需要改動，這次重構(gòu)工作量非常小，運行代碼，一切正常，重構(gòu)成功。
總結(jié)
這就是職責(zé)鏈模式的使用。和狀態(tài)模式有點像，解決了以下問題：
- 通過添加子類把一些邏輯判斷從調(diào)用類（VaccationApproveSystem）移到子類的方式，使得調(diào)用類滿足迪米特法則
- 想在職責(zé)鏈上面添加更多節(jié)點的時候，只需要添加新類和修改鏈組裝部分的代碼，基本滿足開閉原則（這里幾乎不可能完全滿足開閉原則，畢竟有修改就意味著我們肯定會改動VaccationApproveSystem類，只是我們應(yīng)該盡量的讓代碼改動量少，以提高控制代碼變動的能力）
和狀態(tài)模式一樣，它也有子類爆炸的風(fēng)險。
可能有朋友會感到疑惑，既然職責(zé)鏈模式和狀態(tài)模式看起來那么像，那它們有什么區(qū)別呢？它們的區(qū)別在于：
- 狀態(tài)模式中的對象是有狀態(tài)的，可以隨時通過接口查詢對象的當前狀態(tài)，對象正是因為有了不同的狀態(tài)，才會表現(xiàn)出不同行為。而職責(zé)鏈模式中的對象沒有狀態(tài)，對象和鏈的關(guān)系更像請求和處理管線的關(guān)系，沒有接口能告訴我們當前在處理管線的哪個節(jié)點，也沒有意義這么做，我們只關(guān)心請求是否被處理了
- 狀態(tài)模式中的狀態(tài)切換可以是無序的，比如，一個游戲角色，當他的狀態(tài)是虛弱的時候，可以通過治療，轉(zhuǎn)換成健康，也可以通過受傷轉(zhuǎn)換成瀕死。而職責(zé)鏈中的請求轉(zhuǎn)發(fā)就只有向前一條路，從小組長到部門經(jīng)理，從部門經(jīng)理到老板
根據(jù)不同的情景，選擇合適的模式，才是正確的使用之道。以上就是今天的內(nèi)容，希望大家喜歡，我們下次見！
以上就是實例講解C#中的職責(zé)鏈模式的詳細內(nèi)容，更多關(guān)于C# 職責(zé)鏈模式的資料請關(guān)注腳本之家其它相關(guān)文章！
相關(guān)文章
這篇文章主要介紹了C# 字段和屬性的的相關(guān)資料，文中示例代碼非常詳細，供大家參考和學(xué)習(xí)，感興趣的朋友可以了解下2020-06-06
在C#開發(fā)過程中,常常會遇到各種各樣的警告信息,本文將結(jié)合多種常見情況,詳細介紹如何處理C#中的一些典型警告,希望對大家有所幫助2024-11-11
這篇文章主要為大家詳細介紹了如何利用C#實現(xiàn)FTP下載文件，文中的示例代碼講解詳細，對我們學(xué)習(xí)C#有一定的幫助，感興趣的小伙伴可以跟隨小編一起了解一下2022-12-12
這篇文章主要介紹了c# 如何實現(xiàn)發(fā)送郵件的功能，文中示例代碼非常詳細，幫助大家更好的理解和學(xué)習(xí)，感興趣的朋友可以了解下2020-07-07
C# DataTable中Compute方法用法集錦(數(shù)值/字符串/運算符/表等操作)
這篇文章主要介紹了C# DataTable中Compute方法用法,總結(jié)分析了DataTable中Compute方法常見的數(shù)值運算操作、字符串操作、運算符操作、表運算等相關(guān)技巧,需要的朋友可以參考下2016-06-06
在很多情況下我們需要將指定的數(shù)據(jù)庫中的所有表都列出來。在使用c#進行軟件開發(fā)時，我們有哪些方法可是實現(xiàn)這個目的呢？本人對此進行概要的總結(jié)，有以下6中方式可以實現(xiàn)這個目的。2010-02-02
這篇文章主要介紹了如何在c#中使用opencv，對圖像匹配處理感興趣的同學(xué)可以參考下2021-04-04
C#在foreach遍歷刪除集合中元素的三種實現(xiàn)方法
這篇文章主要給大家總結(jié)介紹了關(guān)于C#在foreach遍歷刪除集合中元素的實現(xiàn)方法，文中通過示例代碼介紹的非常詳細，對大家學(xué)習(xí)或者使用C#具有一定的參考學(xué)習(xí)價值，需要的朋友們下面來一起學(xué)習(xí)學(xué)習(xí)吧2019-12-12
ThreadPool 是 .net 2.0 時代的產(chǎn)物，有了 Thread 為什么還會有 ThreadPool 呢？ThreadPool 可以做到限制線程數(shù)量、重用線程2021-11-11
這篇文章介紹了C#操作結(jié)束進程及子進程的方法，文中通過示例代碼介紹的非常詳細。對大家的學(xué)習(xí)或工作具有一定的參考借鑒價值，需要的朋友可以參考下2022-06-06