一說到「設計模式」,可能不少人都有聽過。html
可是若是真的要你說說應用場景,可能會有點「難以描述」。android
除了應用場景比較多的單例模式你可以信手拈來,其餘的可能會以爲有點難以掌握。也許壓根都沒用過。git
今天,經過本篇文章,讓你對責任鏈模式也可以信手拈來。程序員
本篇文章經過實際項目中的例子來讓你認識何爲責任鏈模式。github
百度百科的介紹:責任鏈模式是一種設計模式。在責任鏈模式裏,不少對象由每個對象對其下家的引用而鏈接起來造成一條鏈。請求在這個鏈上傳遞,直到鏈上的某一個對象決定處理此請求。發出這個請求的客戶端並不知道鏈上的哪個對象最終處理這個請求,這使得系統能夠在不影響客戶端的狀況下動態地從新組織和分配責任。設計模式
維基百科的介紹:責任鏈模式在面向對象程式設計裏是一種軟件設計模式,它包含了一些命令對象和一系列的處理對象。每個處理對象決定它能處理哪些命令對象,它也知道如何將它不能處理的命令對象傳遞給該鏈中的下一個處理對象。該模式還描述了往該處理鏈的末尾添加新的處理對象的方法。ide
個人介紹:顧名思義,責任鏈模式是一條鏈,鏈上有多個節點,每一個節點都有各自的責任。當有輸入時,第一個責任節點看本身可否處理該輸入,若是能夠就處理。若是不能就交由下一個責任節點處理。依次類推,直到最後一個責任節點。學習
定義老是有點文縐縐,仍是看下下面的例子加深下理解吧。測試
舉幾個例子:優化
1. 需求開發例子
假設如今有個需求來了,首先是實習生拿到這個需求。
若是實習生可以實現,直接實現。若是不行,他把這個需求交給初級工程師。
若是初級工程師可以實現,直接實現。若是不行,交給中級工程師。
若是中級工程師可以實現,直接實現。若是不行,交給高級工程師。
若是高級工程師可以實現,直接實現。若是不行,交給 CTO。
若是 CTO可以實現,直接實現。若是不行,直接跟產品說,需求不作。
對於程序員來講,沒有實現不了的需求,只有不想作的需求
2. 買球籃例子
假設你如今有個籃球,而後想要買個球籃。
你確定是到店裏,讓老闆把全部尺寸的球籃拿出來。
而後你一個一個試。
第一個不行,就第二個。
第二個不行,就第三個。
...
直到找到合適的。
經過定義和列舉的例子,你們對於責任鏈模式應該有點熟悉了。
是否是以爲本身平時寫的代碼中好像有用到的樣子,有點熟悉?
不要急,接下來咱們給你們看看一些熟悉的代碼,這裏以 Java 代碼爲例子,其餘語言也是相似的。
給定一個輸入值,根據輸入值執行不一樣邏輯。
咱們一看,分分鐘寫出以下代碼:
String input = "1"; if ("1".equals(input)) { //TODO do something } else if ("2".equals(input)) { //TODO do something } else if ("3".equals(input)) { //TODO do something }
或者以下代碼:
String input = "1"; switch (input) { case "1": //TODO do something break; case "2": //TODO do something break; case "3": //TODO do something break; default: //TODO do something break; }
若是每一個分支裏面的邏輯比較簡單,那還好,若是邏輯複雜,**假設每一個 case 大概要 100 行代碼處理,有 10 個 case,一會兒就出來一個「千行代碼」文件。**並且還不利於維護、測試和擴展。
若是可以想辦法把代碼拆分紅每一個 case 一個文件,這樣不只代碼邏輯清晰了不少,並且不論是後續維護、擴展仍是進行測試,都方便不少。
所以,本篇文章核心,責任鏈模式的妙用——拆分代碼就來了。
這裏以上面場景爲例子進行拆分代碼說明,其餘場景相信你們可以觸類旁通。
1. 定義一個抽象類。
public abstract class BaseCase { // 爲 true 代表本身能夠處理該 case private boolean isConsume; public BaseCase(boolean isConsume) { this.isConsume = isConsume; } // 下一個責任節點 private BaseCase nextCase; public void setNextCase(BaseCase nextCase) { this.nextCase = nextCase; } public void handleRequest() { if (isConsume) { // 若是當前節點能夠處理,直接處理 doSomething(); } else { // 若是當前節點不能處理,而且有下個節點,交由下個節點處理 if (null != nextCase) { nextCase.handleRequest(); } } } abstract protected void doSomething(); }
註釋已經寫的很清楚了。這裏就再也不贅述。
2. 各個 case 來實現該抽象類。
這裏列舉一個 case,其餘能夠看代碼。
public class OneCase extends BaseCase { public OneCase(boolean isConsume) { super(isConsume); } @Override protected void doSomething() { // TODO do something System.out.println(getClass().getName()); } }
3. 初始化各個 case,並指定每一個 case 的下一個節點。
String input = "1"; OneCase oneCase = new OneCase("1".equals(input)); TwoCase twoCase = new TwoCase("2".equals(input)); DefaultCase defaultCase = new DefaultCase(true); oneCase.setNextCase(twoCase); twoCase.setNextCase(defaultCase); oneCase.handleRequest();
好了,到此咱們責任鏈模式拆分代碼就告一段落了。
上面是責任鏈模式拆分代碼的一個基本實現。
後面有同事給了建議,說能夠參考 OkHttp 裏面的 Interceptor 實現。
因此這邊看了一下,作了以下改進。
先說一下大概思想吧。
將全部的 case 集中起來,經過遍歷肯定可以處理的 case。
一樣是以上面的場景爲例進行說明。
1. 定義一個接口。
interface BaseCase { // 全部 case 處理邏輯的方法 void doSomething(String input, BaseCase baseCase); }
2. 創建一個責任鏈管理類,管理全部 case。
public class CaseChain implements BaseCase { // 全部 case 列表 private List<BaseCase> mCaseList = new ArrayList<>(); // 索引,用於遍歷全部 case 列表 private int index = 0; // 添加 case public CaseChain addBaseCase(BaseCase baseCase) { mCaseList.add(baseCase); return this; } @Override public void doSomething(String input, BaseCase baseCase) { // 全部遍歷完了,直接返回 if (index == mCaseList.size()) return; // 獲取當前 case BaseCase currentCase = mCaseList.get(index); // 修改索引值,以便下次回調獲取下個節點,達到遍歷效果 index++; // 調用 當前 case 處理方法 currentCase.doSomething(input, this); } }
3. 各個 case 實現接口。這裏以其中一個爲例。
public class OneCase implements BaseCase { @Override public void doSomething(String input, BaseCase baseCase) { if ("1".equals(input)) { // TODO do something System.out.println(getClass().getName()); return; } //當前無法處理,回調回去,讓下一個去處理 baseCase.doSomething(input, baseCase); } }
4. 初始化各個 case
String input = "1"; CaseChain caseChain = new CaseChain(); caseChain.addBaseCase(new OneCase()) .addBaseCase(new TwoCase()) .addBaseCase(new DefaultCase()); caseChain.doSomething(input, caseChain);
好了,註釋寫的很清楚,相信你們看懂是沒問題的。
至此,咱們的責任鏈模式已經講完了。
相信你對於責任鏈模式已經熟記於心了。
若是你還有點疑問
能夠留言,看下代碼或者敲敲代碼。
本篇文章以實際項目中的場景爲例,向你描述責任鏈模式的妙用。
看完文章,可能你只學到其形,而沒有學到其神。
經過不斷的使用以及本身經驗的不斷積累,相信達到形神兼備也是時間問題而已。
等你徹底掌握以後,再也不是「我要用責任鏈模式,所以寫出了代碼」。
而是「我寫出了代碼,才發現用到了責任鏈模式」。
正如《倚天屠龍記》裏面張三丰教張無忌太極劍時,最後張無忌全都忘了同樣。
舒適提示:
學習了新設計模式,不免有點手癢。
可是切記不要濫用設計模式。
不要爲了設計而設計。
好比你就幾個 case,並且處理邏輯就是彈個框。
你說你要用上設計模式?這樣成本會更高,其實不必。
因此學會是一回事,何時用又是另外一回事了。
以爲不錯,歡迎轉發分享。
參考:
http://www.runoob.com/design-pattern/chain-of-responsibility-pattern.html