主目錄見：Android高級進階知識（這是總目錄索引）
?學習設計模式，個人覺得第一就是不能局限于一個思維，也許些許的變化有時能讓它更加符合你的設計，所以我們不要拘泥于固定的角色，生搬硬套的場景，我們要經得起變化。這也是為什么會有那么多的變形的原因。我們今天要講責任鏈設計模式(chain of responsibility)，這個模式也是會有很多的變形，我們待會會在分析例子的過程中講到。我們先來看下它的定義：
責任鏈模式是一種對象的行為模式。在責任鏈模式里，很多對象由每一個對象對其下家的引用而連接起來形成一條鏈。請求在這個鏈上傳遞，直到鏈上的某一個對象決定處理此請求。發出這個請求的客戶端并不知道鏈上的哪一個對象最終處理這個請求，這使得系統可以在不影響客戶端的情況下動態地重新組織和分配責任。
這個定義非常明確地說明了責任鏈模式的作用，很多對象由每一個對象對其下家的引用而連接起來形成一條鏈也就是說請求向上傳遞過程中，如果自己不處理的話，那么由于自己持有了下家的引用，所以可以交給下家去處理，這樣循環下去直到有對象想要處理。我們接著來看看UML類圖：
角色介紹：
Handler:抽象處理者，聲明一個請求的處理方法，并保持對下一個處理節點Handler對象的引用。
ConcreteHandler:具體處理者，對請求進行處理，如果不處理就講請求轉發給下一個節點上的處理對象。
一.目標
講這個設計模式，是覺得他用的地方還是蠻廣的，而且我們最熟悉的事件分發應該就是典型的責任鏈設計模式吧，所以我們今天目標也是：
1.明白責任鏈設計模式怎么使用；
2.知道在什么場景需要用到責任鏈設計模式。
二.模式分析
同樣地，我們今天也先假設一個場景，公司有一天安排你去出差，那你說我要申請費用500塊，然后你申請表就提交給組長，組長說數額太大不歸我管，讓主管來吧，主管也說這個我也不能管，讓經理來吧，經理一甩手，允許了，然后你就拿著錢屁顛屁顛出差去了。這里我們首先看看我們抽象處理者角色：
public abstract class Handler {
protected int expenses;
protected Handler mNextChain;
public Handler(int expenses){
this.expenses = expenses;
}
public void setNextHandler(Handler handler){
this.mNextChain = handler;
}
public abstract void handleRequest(Request request);
}
我們看到這是一個典型的抽象處理者角色，里面有設置下家的引用setNextHandler()，還有處理條件expenses，處理方法handleRequest()。然后我們分別來看幾個具體的處理者角色首先是組長：
public class TeamLeader extends Handler{
public TeamLeader() {
super(200);
}
@Override
public void handleRequest(Request request) {
if (request.getApplyExpense() > this.expenses&& mNextChain != null) {
this.mNextChain.handleRequest(request);
}else{
System.out.println("組長批準了");
}
}
}
我們看到這里處理條件傳進去200，說明我只能處理兩百塊的出差申請，然后如果費用太高只能讓上面的人來審批，當然這里判斷不充分，但是anyway，我們只要了解思想即可。接著我們看下一個處理者：
public class ApartmentDirector extends Handler{
public ApartmentDirector() {
super(400);
}
@Override
public void handleRequest(Request request) {
if (request.getApplyExpense() > this.expenses && mNextChain != null) {
this.mNextChain.handleRequest(request);
}else{
System.out.println("主管批準了");
}
}
}
我們看到這里的處理條件是400，接著我們看下一個處理者：
public class ApartmentManager extends Handler{
public ApartmentManager() {
super(500);
}
@Override
public void handleRequest(Request request) {
if (request.getApplyExpense() > this.expenses) {
//this.mNextChain.handleRequest(request);
System.out.println("不符合公司規定");
}else{
System.out.println("經理批準了");
}
}
}
到這里我們所有的處理者都已經出現了，接著就是我們的請求對象了。我們同樣建一個請求者的抽象角色：
public abstract class Request {
public int requestExpense;
public Request(int expense){
this.requestExpense = expense;
}
public int getApplyExpense(){
return this.requestExpense;
}
}
然后建一個具體的請求者角色：
public class BusinessRequest extends Request{
public BusinessRequest() {
super(500);
}
}
到這里我們所有的角色都已經完成了，我們看下我們這個責任鏈是怎么使用的：
Handler teamLeader = new TeamLeader();
Handler apartmentDirector = new ApartmentDirector();
Handler apartmentManager = new ApartmentManager();
//設置鏈式關系
teamLeader.setNextHandler(apartmentDirector);
apartmentDirector.setNextHandler(apartmentManager);
//請求事件
Request request = new BusinessRequest();
//處理請求
teamLeader.handleRequest(request);
我們看到我們請求傳到這條鏈式調用關系上面去，然后根據申請的費用額度每個經理人會判斷是否處理。但是這里有個問題，我們不能得到下家的反饋，也許我們需要對下家反饋做一個再處理呢？那么我們這里把這個變型一下。
1.改版后的責任鏈設計模式
我們首先來看抽象處理者。
public abstract class Handler {
protected int expenses;
protected Handler mNextChain;
public Handler(int expenses){
this.expenses = expenses;
}
public void setNextHandler(Handler handler){
this.mNextChain = handler;
}
public abstract String handleRequest(Request request);
}
我們看到這里唯一的不同是我們這里handleRequest()方法增加了String返回值表示我們的處理返回值。然后我們先來看看組長角色：
public class TeamLeader extends Handler{
public TeamLeader() {
super(200);
}
@Override
public String handleRequest(Request request) {
if (request.getApplyExpense() > this.expenses&& mNextChain != null) {
String response = this.mNextChain.handleRequest(request);
if ("不符合公司規定".equalsIgnoreCase(response)) {
return "先給你批準"+this.expenses;
}else{
return response;
}
}else{
return "組長批準了";
}
}
}
我們看到了，這里針對下家處理返回的值還進行了處理，也就是說我們每一個節點都可以針對這個進行處理包裝和返回結果。達到了功能增強的作用。另外兩個節點也是類似，我就不具體貼出來代碼了，之所以講這個是因為我們OkHttp中用的責任鏈設計模式就是我們改版的模型。我們直接來欣賞下吧。
2.OkHttp中的責任鏈設計模式
我們上次已經說過了OkHttp的源碼了，如果有興趣可以看OkHttp源碼分析，這里我們先來貼一張原理圖：
我們知道非常關鍵的地方就是一系列的攔截器，每個攔截器負責不同的功能，然后針對下個攔截器的返回reponse進行再處理。首先我們來看抽象處理者角色：
public interface Interceptor {
Response intercept(Chain chain) throws IOException;
interface Chain {
Request request();
Response proceed(Request request) throws IOException;
//省略一些跟講解無關代碼
......
}
}
我們看到proceed方法就是我們這里傳遞處理的方法。然后程序會講實現了Interceptor接口的攔截器添加到攔截器集合里面：
Response getResponseWithInterceptorChain() throws IOException {
// Build a full stack of interceptors.
List<Interceptor> interceptors = new ArrayList<>();
interceptors.addAll(client.interceptors());
interceptors.add(retryAndFollowUpInterceptor);
interceptors.add(new BridgeInterceptor(client.cookieJar()));
interceptors.add(new CacheInterceptor(client.internalCache()));
interceptors.add(new ConnectInterceptor(client));
if (!forWebSocket) {
interceptors.addAll(client.networkInterceptors());
}
interceptors.add(new CallServerInterceptor(forWebSocket));
Interceptor.Chain chain = new RealInterceptorChain(interceptors, null, null, null, 0,
originalRequest, this, eventListener, client.connectTimeoutMillis(),
client.readTimeoutMillis(), client.writeTimeoutMillis());
return chain.proceed(originalRequest);
}
然后在RealInterceptorChain的里面會調用proceed進行攔截器里面方法的調用：
// Call the next interceptor in the chain.
RealInterceptorChain next = new RealInterceptorChain(interceptors, streamAllocation, httpCodec,
connection, index + 1, request, call, eventListener, connectTimeout, readTimeout,
writeTimeout);
Interceptor interceptor = interceptors.get(index);
Response response = interceptor.intercept(next);
然后我們看到攔截器(也就是我們具體處理者角色),這里面的代碼，首先我們看第一個攔截器retryAndFollowUpInterceptor攔截器：
@Override public Response intercept(Chain chain) throws IOException {
.....
try {
response = realChain.proceed(request, streamAllocation, null, null);
releaseConnection = false;
} catch (RouteException e) {
....
} catch (IOException e) {
....
} finally {
....
}
.......
}
我們看到這里的proceed方法又交給了下個攔截器處理，那么我們來看下個攔截器BridgeInterceptor：
@Override public Response intercept(Chain chain) throws IOException {
....
Response networkResponse = chain.proceed(requestBuilder.build());
HttpHeaders.receiveHeaders(cookieJar, userRequest.url(), networkResponse.headers());
Response.Builder responseBuilder = networkResponse.newBuilder()
.request(userRequest);
......
return responseBuilder.build();
}
我們看到這個攔截器也調用了proceed方法把請求提交給下個攔截器，以此類推，下面的攔截器都是有這個操作，直到最后一個攔截器把結果返回，然后才會一級一級回歸到第一個攔截器，然后對結果進行再處理，這里的第一個攔截器就是執行的重新請求等一些處理的。
總結：所以我們看到責任鏈設計模式不僅可以針對鏈式中每個節點處理結果進行增強(OkHttp中的攔截器)，而且可以針對請求進行截斷(事件分發機制)，可想而知，這個設計模式使用還是非常廣泛的，希望這里說的有什么不足大家可以提出來。
