設計模式（13）職責鏈模式

行為型模式關注物件之間互動，物件之間的通訊與協作。共十乙個，職責鏈模式是其中之一。

為什麼職責鏈模式屬於行為型模式，因為他很好的體現了物件之間的通訊與協作，職責鏈，就是說在這條鏈上的物件都有這個職責，有職責來做什麼呢？處理請求。

舉個例子，公司審批活動經費，小於5000，副經理就有許可權審批，5000-10000，需要經理審批，10000-50000董事長審批，大於50000，召開董事會決定。

在這種情況下，如果不使用職責連模式會怎麼寫呢，在客戶端進行金額範圍判斷，然後new物件處理請求。這樣寫下來客戶端和各請求處理者（經理，董事長等）耦合性太強了，擴充套件性自然就很差。如果使用職責鏈模式呢？看下面示例：

職責鏈模式uml類圖：

示例**：

抽象處理者：

/****
* 抽象處理者（經理、董事長等處理者父類）
* @author wjw
* */
public abstract class handler 
public abstract void handlerequest(int amount);
}

副經理處理者：

/****
* 副經理類，有處理5000以下金額許可權
* @author wjw
* */
public class deputygeneralmanager extends handlerelse
}}

經理處理者：

/****
* 經理類（處理5000-10000）
* @author wjw
* */
public class generalmanager extends handlerelse
}}

董事長處理者:

/****
* 董事長（處理10000-50000）
* @author wjw
* */
public class chairman extends handlerelse
}}

董事會處理者：

/****
* 董事會（處理50000以上金額）
* @author wjw
* */
public class boardofdirectors extends handlerelse
}}

main：

public class main 
}

執行結果：

你們都沒我屌，讓我來處理了這個大於50000申請吧！

職責鏈模式說明：以上例子很簡單，主要理解職責鏈這個模式，職責鏈需要構建乙個請求處理的鏈，這個鏈的修改和擴充套件也很容易，不必修改源**，直接擴充套件處理者即可。我們有請求，直接將請求傳送給職責鏈的一頭，他自己就會按照我們的鏈執行下去。

就好像例子中的，我們將80000的活動經費申請報告提交給副經理，副經理一看，呀，我級別太低，不夠許可權批這麼多的經費，交給經理吧，經理一看，我也不行啊，給董事長吧，董事長一看，這太多了，公司是大家的，花這麼多錢得大家研究研究，提交到董事會決定吧。於是走了一遍職責鏈。

如有錯誤，歡迎指正

end

設計模式（13） 職責鏈模式