13、Python與設計模式--責任鍊模式一、請假系統二、責任鍊模式三、責任鍊模式的優點和應用場景四、責任鍊模式的缺點

假設有這麼一個請假系統：員工若想要請3天以内（包括3天的假），隻需要直屬經理準許就可以了；如果想請3-7天，不僅需要直屬經理準許，部門經理需要最終準許；如果請假大于7天，不光要前兩個經理準許，也需要總經理最終準許。類似的系統相信大家都遇到過，那麼該如何實作呢？首先想到的當然是if…else…，但一旦遇到需求變動，其臃腫的代碼和複雜的耦合缺點都顯現出來。簡單分析下需求，“假條”在三個經理間是單向傳遞關系，像一條鍊條一樣，因而，我們可以用一條“鍊”把他們進行有序連接配接。

構造抽象經理類和各個層級的經理類：

request類封裝了假期請求。在具體的經理類中，可以通過setsuccessor接口來建構“責任鍊”，并在handlerequest接口中實作邏輯。場景類中實作如下：

列印如下：

line manager:ask 1 day off num:1 accepted over

line manager:ask 5 days off num:5 accepted continue

department manager:ask 5 days off num:5 accepted over

line manager:ask 10 days off num:10 accepted continue

department manager:ask 10 days off num:10 accepted continue

general manager:ask 10 days off num:10 accepted over

責任鍊模式的定義如下：使多個對象都有機會處理請求，進而避免了請求的發送者和接收者之間的耦合關系。将這些對象連成一條鍊，并沿着這條鍊傳遞該請求，直到有對象處理它為止。

需要說明的是，責任鍊模式中的應該隻有一個處理者，也就是說，本例中的“最終準許”為該對象所謂的“請求處理”。

優點：

1、将請求者與處理者分離，請求者并不知道請求是被哪個處理者所處理，易于擴充。

應用場景：

1、若一個請求可能由一個對請求有鍊式優先級的處理群所處理時，可以考慮責任鍊模式。除本例外，銀行的客戶請求處理系統也可以用責任鍊模式實作（vip客戶和普通使用者處理方式當然會有不同）。

1、如果責任鍊比較長，會有比較大的性能問題；

2、如果責任鍊比較長，若業務出現問題，比較難定位是哪個處理者的問題。