職責鏈模式1

來考慮這樣乙個功能：申請聚餐費用的管理。

很多公司都有這樣的福利，就是專案組或者是部門可以向公司申請一些聚餐費用，用於組織專案組成員或者是部門成員進行聚餐活動，以增進人員之間的情感，更有利於工作中的相互合作。

申請聚餐費用的大致流程一般是：由申請人先填寫申請單，然後交給領導審查，如果申請批准下來了，領導會通知申請人審批通過，然後申請人去財務核領費用，如果沒有核准，領導會通知申請人審批未通過，此事也就此作罷了。

不同級別的領導，對於審批的額度是不一樣的，比如：專案經理只能審批500元以內的申請；部門經理能審批1000元以內的申請；而總經理可以審核任意額度的申請。

也就是說，當某人提出聚餐費用申請的請求後，該請求會由專案經理、部門經理、總經理之中的某一位領導來進行相應的處理，但是提出申請的人並不知道最終會由誰來處理他的請求，一般申請人是把自己的申請提交給專案經理，或許最後是由總經理來處理他的請求，但是申請人並不知道應該由總經理來處理他的申請請求。

那麼該怎樣實現這樣的功能呢？

分析上面要實現的功能，主要就是要根據申請費用的多少，然後讓不同的領導來進行處理就可以實現了。也就是有點邏輯判斷而已，示例**如下：

/*** 處理聚餐費用申請的物件

*/public class feerequest else if(fee < 1000)else if(fee >= 1000)

return str;

}/**

* 專案經理審批費用申請，引數、返回值和上面是一樣的，省略了

*/private string projecthandle(string user, double fee) else

return str;

}/**

* 部門經理審批費用申請，引數、返回值和上面是一樣的，省略了

*/private string depmanagerhandle(string user, double fee) else

return str;

}/**

* 總經理審批費用申請，引數、返回值和上面是一樣的，省略了

*/private string generalmanagerhandle(string user, double fee) else

return str;}}

寫個客戶端來測試看看效果，示例**如下：

public class client

}執行結果如下：

the ret1=專案經理同意小李聚餐費用300.0元的請求

the ret2=專案經理不同意小張聚餐費用300.0元的請求

the ret3=部門經理同意小李聚餐費用600.0元的請求

the ret4=部門經理不同意小張聚餐費用600.0元的請求

the ret5=總經理同意小李聚餐費用1200.0元的請求

the ret6=總經理不同意小張聚餐費用1200.0元的請求

上面的實現很簡單，基本上沒有什麼特別的難度。仔細想想，這麼實現有沒有問題呢？仔細分析申請聚餐費用的業務功能和目前的實現，主要面臨著如下問題：

如果採用上面的實現，要是處理的邏輯發生了變化，解決的方法，乙個是生成乙個子類，覆蓋requesttoprojectmanager方法，然後在裡面實現新的處理；另外乙個方法就是修改處理申請的方法的源**來實現。要是具體處理環節的業務處理的功能發生了變化，那就只好找到相應的處理方法，進行源**修改了。

總之都不是什麼好方法，也就是說，如果出現聚餐費用申請的處理流程變化的情況，或者是出現各個處理環節的功能變化的時候，上面的實現方式是很難靈活的變化來適應新功能的要求的。

把上面的問題抽象一下：客戶端發出乙個請求，會有很多物件都可以來處理這個請求，而且不同物件的處理邏輯是不一樣的。對於客戶端而言，無所謂誰來處理，反正有物件處理就可以了。

而且在上述處理中，還希望處理流程是可以靈活變動的，而處理請求的物件需要能方便的修改或者是被替換掉，以適應新的業務功能的需要。

請問如何才能實現上述要求？