物件導向程式設計思想 責任鏈模式

2022-01-11 20:47:49 字數 3199 閱讀 2702

一、引言

你在公司裡請過假嗎?員工向管理者發出請求,每個管理者都有可能接收到請求,將這些管理者串成乙個鍊子,直到有處理這個請求為止。目前我們公司請假制度是:2天以內專案經理審批即可,3天以內專案總監參與審批,超過3天的休假必須經過總經理簽字批准。這個常見的生活場景就用到了我們今天要學習的內容,責任鏈模式。

二、責任鏈模式

定義:使多個物件都有機會處理請求,從而避免請求的發出者和接收者之間的耦合關係。將這個物件鏈成一條鏈,並沿著這條鏈傳遞該請求,直到有乙個物件處理它為止

下面是責任鏈模式結構圖:

下面是**demo:

//

抽象處理角色類

abstract

class

handler

//處理請求

public

abstract

void handle(int

request);

}//具體處理類

class

concretehandlera : handler

處理請求");

}//如果不可以,判斷是否有後繼角色,如果有,交予後繼角色處理

else

if(seccessor!=null

) }}

class

concretehandlerb : handler

處理請求");

}else

if (seccessor != null

) }}

class

concretehandlerc:handler

處理請求");

}else

if (seccessor != null

) }}

class

program

;foreach (int item in

requests)

console.read();}}

view code

分析:由具體handler類組成責任鏈,但鏈物件並不知道鏈整體結構,簡化物件的相互連線。它們只需要保持下乙個後繼者的引用,而不需要保持所有候選者的引用,降低了耦合度。可以隨時增加或修改乙個請求的結構,增加了給物件指派職責的靈活性。

下面是解決開篇的生活例子,**demo

//

請求類class

request

}//審批人

abstract

class

handler

public

string

name;

public handler(string

name)

public

abstract

void

handle(request request);

}//專案經理

class

concretehandlea : handler

public

override

void

handle(request request)

:數量為,被批准");

}else

if(nexthandle!=null

) }}

//專案總監

class

concretehandleb:handler

public

override

void

handle(request request)

:數量為,被批准");

}else

if (nexthandle != null

) }}

//總經理

class

concretehandlec:handler

public

override

void

handle(request request)

:數量為,被批准");

}else

if (request.typename == "

加薪" && request.count < 2000

) :數量為,被批准");

}else

if (request.typename == "

加薪" && request.count > 5000

) :數量為,我再想想吧");}}

}class

program

}

view code

分析:不同的請假天數決定不同的審批者,如果把所有的審批者放在乙個物件裡,顯然是破壞「開-閉」原則的,不利於擴充套件。我們盡可能的封裝變化,根據不同的請求,建立多個審批類,每個類負責自己範圍內的職責,設定上級審批者,如果不在職責範圍交予上級審批,這樣也就形成了職責鏈。

純的責任鏈模式:要求乙個具體處理者物件只能在兩個行為中選擇乙個,一是承擔責任,二是把責任推給下家,不允許出現某乙個具體的處理者物件在承擔了一部分責任後又把責任推給下家。請求在責任鏈中必須被處理不能出現無果而終的解決

不純的責任鏈模式:乙個請求可以最終不被任何接收端物件所接收

優點:

1.降低耦合度。請求接收者和傳送者都沒有對方明確資訊,且鏈中物件不需要知道鏈結構

2.職責鏈可簡化物件之間的鏈結。它僅需要保持乙個後繼者的引用,而不需要保持它所有候選者的引用

3.增加給物件指派職責的靈活性。可以在執行時刻動態的增加或修改處理乙個請求的那些指責

缺點:

1.不能保證請求一定被接收。請求沒有明確的接收者,可能到鏈末端也得不到處理。

2.責任鏈過長,系統效能可能受到影響;除錯起來不方便

適用場景:

1.有多個的物件處理請求,哪個物件處理請求執行時刻自動確定

2.在不明確接收者的情況下,向多個物件中的乙個提交乙個請求

物件導向程式設計思想 狀態模式

一 引言 上篇部落格中學習了中介者模式,我們留下了乙個問題,當出現多個玩家需要輸贏狀態條件判斷時,可不可以不去修改中介者類,因為如果每新增乙個條件判斷,就要修改中介者類,破壞了封裝,違背開閉原則。今天我們學習的內容就是要解決這種業務場景,狀態模式 二 狀態模式 定義 當乙個物件的內在狀態改變時允許改...

物件導向程式設計思想 命令模式

一 引言 起初餐館吃飯都是客人和廚師直接溝通,菜譜是一樣的,可是客人多了的時候,有的客人可能有急事不吃了要退單,還有的客人點很多菜需要記錄類別和次序等現象,這時服務員角色的出現解決了問題。那麼面對某些無法抵禦變化的 緊耦合 的場景如何做程式設計呢?命令模式設計便出現了,使得 行為請求者 與 行為實現...

物件導向程式設計思想 外觀模式

一 引言 每逢去吃午飯路上,幾個同事都要討論一番投資理財的事情,時間久之,小白的我才勉強了解到 與 的區別,是自身直接與某只 交易,可以通過分紅或者低買高賣獲利 自身需要分析 多隻 的 如圖示一 而 是把錢交給 公司,有專業人員幫你分析 或債券等幫你理財 自身不需要直接關注 了,見圖示二 圖示一 圖...