16.4 最佳實踐 在例子和通用源碼中Handler是抽象類，融合了模板方法模式，每個實現類只要實現兩個方法：echo方法處理請求和getHandlerLevel獲得處理級別，想想單一職責原則和迪米特法則吧，通過融合模板方法模式，各個實現類只要關注的自己業務邏輯就成了，至于說什么事要自己處理，那就讓父類去決定好了，也就是說父類實現了請求傳遞的功能，子類實現請求的處理，符合單一職責原則，各個實現類只完成一個動作或邏輯，也就是只有一個原因引起類的改變，我建議大家在使用的時候用這種方法，好處是非常明顯的了，子類的實現非常簡單，責任鏈的建立也是非常靈活的。 責任鏈模式屏蔽了請求的處理過程，你發起一個請求到底是誰處理的，這個你不用關心，只要你把請求拋給責任鏈的第一個處理者，最終會返回一個處理結果（當然也可以不做任何處理），作為請求者可以不用知道到底是需要誰來處理的，這是責任鏈模式的核心，同時責任鏈模式也可以作為一種補救模式來使用。舉個簡單例子，如項目開發的時候，需求確認是這樣的：一個請求（如銀行客戶存款的幣種），一個處理者（只處理人民幣），但是隨著業務的發展（改革開放了嘛，還要處理美元、日元等），處理者的數量和類型都有所增加，那這時候就可以在第一個處理者后面建立一個鏈，也就是責任鏈來處理請求，如果是人民幣，好，還是第一個業務邏輯來處理；如果是美元，好，傳遞到第二個業務邏輯來處理；日元、歐元……這些都不用在對原有的業務邏輯產生很大改變，通過擴展實現類就可以很好地解決這些需求變更的問題。 責任鏈在實際的項目中使用也是比較多的，我曾經做過這樣一個項目，界面上有一個用戶注冊功能，注冊用戶分兩種，一種是VIP用戶，也就是在該單位辦理過業務的，一種是普通用戶，一個用戶的注冊要填寫一堆信息，VIP用戶只比普通用戶多了一個輸入項：VIP序列號。注冊后還需要激活，VIP和普通用戶的激活流程也是不同的，VIP是自動發送郵件到用戶的郵箱中就算激活了，普通用戶要發送短信才能激活，為什么呢？獲得手機號碼以后好發廣告短信啊！項目組就采用了責任鏈模式，甭管從前臺傳遞過來的是VIP用戶信息還是普通用戶信息，統一傳遞到一個處理入口，通過責任鏈來完成任務的處理，類圖如圖16-5所示。  圖16-5 用戶注冊類圖 其中RegisterAction是繼承了Strust2中的ActionSupport，實現HTTP傳遞過來對象組裝，組裝出一個HashMap對象UserInfoMap，傳遞給Handler的兩個實現類，具體是哪個實現類來處理的，就由HashMap上的用戶標識來做決定了，這個和上面我們舉的例子很類似，讀者可以自行實現。