代碼執行結果如下圖（後面一圖為注釋掉InitGM()方法中初始化managerTeam代碼的執行結果）：
代碼說明
l Case類代表了問題。CaseCategory屬性代表了問題的分類，普通客服和客服經理處理不同分類的問題。ImportantCase屬性代表了問題是否是重要問題，如果是重要問題，則需要上級領導審核。Reply屬性代表了客服對問題的回復。
l CustomerService類是責任鏈模式中的抽象處理者。我們看到，它定義了下個責任人的引用，並且提供了設置這個責任人的方法。當然，它也定義了統一的處理接口。
l NormalGM是具體處理者，它實現了處理接口。在這裡，我們看到普通客服的處理邏輯是，如果這個問題的分類在它負責的分類之外則直接提交給上級領導進行處理（把對象通過責任鏈傳遞），否則就回復問題，回復問題之後看這個問題是否是重要問題，如果是重要問題則給上級領導進行審核，否則問題處理結束。
l GMManager也是一個具體處理者。客服經理處理問題的邏輯是，首先判斷問題的問題是否在它負責的分類之內，如果是的話則進行處理（重要問題同樣提交給上級處理），如果不是的話就看問題是否有了回復，如果有回復說明是要求審核的問題，審核後問題回復，如果問題還沒有回復則提交給上級處理。
l GMDirector的處理流程就相對簡單了，它並沒有上級了，因此所有問題必須在它這裡結束。對於沒有回復的問題則進行回復，對於要求審核的問題則進行審核。
l 再來看看客戶端的調用。首先，執行了InitGM()方法來初始化客服團隊的數據，在這裡我們的團隊中有9個普通客服、2個客服經理和1個客服總監。普通客服只能回復分類1和分類2的問題，而客服經理只能回復分類3和分類4的問題。
l 然後，調用InitCOR()方法來初始化責任鏈，在這裡我們並沒有簡單得設置普通客服的上級是客服經理、客服經理的上級是客服總監，而是自動根據是否有客服經理這個角色來動態調整責任鏈，也就是說如果沒有客服經理的話，普通客服直接向客服總監匯報。
l 最後，我們模擬了一些問題數據進行處理。對於客戶端（玩家）來說任何普通客服角色都是一樣的，因此我們為所有問題隨機分配了普通客服作為責任鏈的入口點。
l 首先來分析有客服經理時的處理情況。分類為1的問題直接由普通客服處理完畢。分類為2的重要問題由普通客服回復後再由客服經理進行審核。分類為3的問題直接由普通客服提交到客服經理進行處理。分類為4的重要問題也直接由普通客服提交到客服經理進行處理，客服經理回復後再提交到客服總監進行審核。分類為5的問題由普通客服提交到客服經理進行處理，客服經理再提交給客服總監進行處理。
l 再來分析沒有客服經理時的處理情況。分類為1的問題直接由普通客服處理完畢。分類為2的重要問題由普通客服回復後再由客服總監進行審核。分類為3的問題直接由普通客服提交到客服總監進行處理。分類為4的重要問題也直接由普通客服提交到客服總監進行處理。分類為5的問題也直接由普通客服提交到客服總監進行處理。
l 如果沒有責任鏈模式，這個處理流程將會多麼混亂。
