# 請求的鏈式處理——職責鏈模式（三）
16.3 完整解決方案
為了讓采購單的審批流程更加靈活，并實現采購單的鏈式傳遞和處理，Sunny公司開發人員使用職責鏈模式來實現采購單的分級審批，其基本結構如圖16-3所示：
在圖16-3中，抽象類Approver充當抽象處理者（抽象傳遞者），Director、VicePresident、President和Congress充當具體處理者（具體傳遞者），PurchaseRequest充當請求類。完整代碼如下所示：
```
//采購單：請求類
class PurchaseRequest {
private double amount; //采購金額
private int number; //采購單編號
private String purpose; //采購目的
public PurchaseRequest(double amount, int number, String purpose) {
this.amount = amount;
this.number = number;
this.purpose = purpose;
}
public void setAmount(double amount) {
this.amount = amount;
}
public double getAmount() {
return this.amount;
}
public void setNumber(int number) {
this.number = number;
}
public int getNumber() {
return this.number;
}
public void setPurpose(String purpose) {
this.purpose = purpose;
}
public String getPurpose() {
return this.purpose;
}
}
//審批者類：抽象處理者
abstract class Approver {
protected Approver successor; //定義后繼對象
protected String name; //審批者姓名
public Approver(String name) {
this.name = name;
}
//設置后繼者
public void setSuccessor(Approver successor) {
this.successor = successor;
}
//抽象請求處理方法
public abstract void processRequest(PurchaseRequest request);
}
//主任類：具體處理者
class Director extends Approver {
public Director(String name) {
super(name);
}
//具體請求處理方法
public void processRequest(PurchaseRequest request) {
if (request.getAmount() < 50000) {
System.out.println("主任" + this.name + "審批采購單：" + request.getNumber() + "，金額：" + request.getAmount() + "元，采購目的：" + request.getPurpose() + "。"); //處理請求
}
else {
this.successor.processRequest(request); //轉發請求
}
}
}
//副董事長類：具體處理者
class VicePresident extends Approver {
public VicePresident(String name) {
super(name);
}
//具體請求處理方法
public void processRequest(PurchaseRequest request) {
if (request.getAmount() < 100000) {
System.out.println("副董事長" + this.name + "審批采購單：" + request.getNumber() + "，金額：" + request.getAmount() + "元，采購目的：" + request.getPurpose() + "。"); //處理請求
}
else {
this.successor.processRequest(request); //轉發請求
}
}
}
//董事長類：具體處理者
class President extends Approver {
public President(String name) {
super(name);
}
//具體請求處理方法
public void processRequest(PurchaseRequest request) {
if (request.getAmount() < 500000) {
System.out.println("董事長" + this.name + "審批采購單：" + request.getNumber() + "，金額：" + request.getAmount() + "元，采購目的：" + request.getPurpose() + "。"); //處理請求
}
else {
this.successor.processRequest(request); //轉發請求
}
}
}
//董事會類：具體處理者
class Congress extends Approver {
public Congress(String name) {
super(name);
}
//具體請求處理方法
public void processRequest(PurchaseRequest request) {
System.out.println("召開董事會審批采購單：" + request.getNumber() + "，金額：" + request.getAmount() + "元，采購目的：" + request.getPurpose() + "。"); //處理請求
}
}
```
編寫如下客戶端測試代碼：
```
class Client {
public static void main(String[] args) {
Approver wjzhang,gyang,jguo,meeting;
wjzhang = new Director("張無忌");
gyang = new VicePresident("楊過");
jguo = new President("郭靖");
meeting = new Congress("董事會");
//創建職責鏈
wjzhang.setSuccessor(gyang);
gyang.setSuccessor(jguo);
jguo.setSuccessor(meeting);
//創建采購單
PurchaseRequest pr1 = new PurchaseRequest(45000,10001,"購買倚天劍");
wjzhang.processRequest(pr1);
PurchaseRequest pr2 = new PurchaseRequest(60000,10002,"購買《葵花寶典》");
wjzhang.processRequest(pr2);
PurchaseRequest pr3 = new PurchaseRequest(160000,10003,"購買《金剛經》");
wjzhang.processRequest(pr3);
PurchaseRequest pr4 = new PurchaseRequest(800000,10004,"購買桃花島");
wjzhang.processRequest(pr4);
}
}
```
編譯并運行程序，輸出結果如下：
```
主任張無忌審批采購單：10001，金額：45000.0元，采購目的：購買倚天劍。
副董事長楊過審批采購單：10002，金額：60000.0元，采購目的：購買《葵花寶典》。
董事長郭靖審批采購單：10003，金額：160000.0元，采購目的：購買《金剛經》。
召開董事會審批采購單：10004，金額：800000.0元，采購目的：購買桃花島。
```
如果需要在系統增加一個新的具體處理者，如增加一個經理(Manager)角色可以審批5萬元至8萬元（不包括8萬元）的采購單，需要編寫一個新的具體處理者類Manager，作為抽象處理者類Approver的子類，實現在Approver類中定義的抽象處理方法，如果采購金額大于等于8萬元，則將請求轉發給下家，代碼如下所示：
```
//經理類：具體處理者
class Manager extends Approver {
public Manager(String name) {
super(name);
}
//具體請求處理方法
public void processRequest(PurchaseRequest request) {
if (request.getAmount() < 80000) {
System.out.println("經理" + this.name + "審批采購單：" + request.getNumber() + "，金額：" + request.getAmount() + "元，采購目的：" + request.getPurpose() + "。"); //處理請求
}
else {
this.successor.processRequest(request); //轉發請求
}
}
}
```
由于鏈的創建過程由客戶端負責，因此增加新的具體處理者類對原有類庫無任何影響，無須修改已有類的源代碼，符合“開閉原則”。
在客戶端代碼中，如果要將新的具體請求處理者應用在系統中，需要創建新的具體處理者對象，然后將該對象加入職責鏈中。如在客戶端測試代碼中增加如下代碼：
```
Approver rhuang;
rhuang = new Manager("黃蓉");
```
將建鏈代碼改為：
```
//創建職責鏈
```
wjzhang.setSuccessor(rhuang); //將“黃蓉”作為“張無忌”的下家
rhuang.setSuccessor(gyang); //將“楊過”作為“黃蓉”的下家
gyang.setSuccessor(jguo);
jguo.setSuccessor(meeting);
```
重新編譯并運行程序，輸出結果如下：
```
主任張無忌審批采購單：10001，金額：45000.0元，采購目的：購買倚天劍。
經理黃蓉審批采購單：10002，金額：60000.0元，采購目的：購買《葵花寶典》。
董事長郭靖審批采購單：10003，金額：160000.0元，采購目的：購買《金剛經》。
召開董事會審批采購單：10004，金額：800000.0元，采購目的：購買桃花島。
```
思考
> 如果將審批流程由“主任-->副董事長-->董事長-->董事會”調整為“主任-->董事長-->董事會”，系統將做出哪些改動？預測修改之后客戶端代碼的輸出結果。
- Introduction
- 基礎知識
- 設計模式概述
- 從招式與內功談起——設計模式概述（一）
- 從招式與內功談起——設計模式概述（二）
- 從招式與內功談起——設計模式概述（三）
- 面向對象設計原則
- 面向對象設計原則之單一職責原則
- 面向對象設計原則之開閉原則
- 面向對象設計原則之里氏代換原則
- 面向對象設計原則之依賴倒轉原則
- 面向對象設計原則之接口隔離原則
- 面向對象設計原則之合成復用原則
- 面向對象設計原則之迪米特法則
- 六個創建型模式
- 簡單工廠模式-Simple Factory Pattern
- 工廠三兄弟之簡單工廠模式（一）
- 工廠三兄弟之簡單工廠模式（二）
- 工廠三兄弟之簡單工廠模式（三）
- 工廠三兄弟之簡單工廠模式（四）
- 工廠方法模式-Factory Method Pattern
- 工廠三兄弟之工廠方法模式（一）
- 工廠三兄弟之工廠方法模式（二）
- 工廠三兄弟之工廠方法模式（三）
- 工廠三兄弟之工廠方法模式（四）
- 抽象工廠模式-Abstract Factory Pattern
- 工廠三兄弟之抽象工廠模式（一）
- 工廠三兄弟之抽象工廠模式（二）
- 工廠三兄弟之抽象工廠模式（三）
- 工廠三兄弟之抽象工廠模式（四）
- 工廠三兄弟之抽象工廠模式（五）
- 單例模式-Singleton Pattern
- 確保對象的唯一性——單例模式 （一）
- 確保對象的唯一性——單例模式 （二）
- 確保對象的唯一性——單例模式 （三）
- 確保對象的唯一性——單例模式 （四）
- 確保對象的唯一性——單例模式 （五）
- 原型模式-Prototype Pattern
- 對象的克隆——原型模式（一）
- 對象的克隆——原型模式（二）
- 對象的克隆——原型模式（三）
- 對象的克隆——原型模式（四）
- 建造者模式-Builder Pattern
- 復雜對象的組裝與創建——建造者模式（一）
- 復雜對象的組裝與創建——建造者模式（二）
- 復雜對象的組裝與創建——建造者模式（三）
- 七個結構型模式
- 適配器模式-Adapter Pattern
- 不兼容結構的協調——適配器模式（一）
- 不兼容結構的協調——適配器模式（二）
- 不兼容結構的協調——適配器模式（三）
- 不兼容結構的協調——適配器模式（四）
- 橋接模式-Bridge Pattern
- 處理多維度變化——橋接模式（一）
- 處理多維度變化——橋接模式（二）
- 處理多維度變化——橋接模式（三）
- 處理多維度變化——橋接模式（四）
- 組合模式-Composite Pattern
- 樹形結構的處理——組合模式（一）
- 樹形結構的處理——組合模式（二）
- 樹形結構的處理——組合模式（三）
- 樹形結構的處理——組合模式（四）
- 樹形結構的處理——組合模式（五）
- 裝飾模式-Decorator Pattern
- 擴展系統功能——裝飾模式（一）
- 擴展系統功能——裝飾模式（二）
- 擴展系統功能——裝飾模式（三）
- 擴展系統功能——裝飾模式（四）
- 外觀模式-Facade Pattern
- 深入淺出外觀模式（一）
- 深入淺出外觀模式（二）
- 深入淺出外觀模式（三）
- 享元模式-Flyweight Pattern
- 實現對象的復用——享元模式（一）
- 實現對象的復用——享元模式（二）
- 實現對象的復用——享元模式（三）
- 實現對象的復用——享元模式（四）
- 實現對象的復用——享元模式（五）
- 代理模式-Proxy Pattern
- 設計模式之代理模式（一）
- 設計模式之代理模式（二）
- 設計模式之代理模式（三）
- 設計模式之代理模式（四）
- 十一個行為型模式
- 職責鏈模式-Chain of Responsibility Pattern
- 請求的鏈式處理——職責鏈模式（一）
- 請求的鏈式處理——職責鏈模式（二）
- 請求的鏈式處理——職責鏈模式（三）
- 請求的鏈式處理——職責鏈模式（四）
- 命令模式-Command Pattern
- 請求發送者與接收者解耦——命令模式（一）
- 請求發送者與接收者解耦——命令模式（二）
- 請求發送者與接收者解耦——命令模式（三）
- 請求發送者與接收者解耦——命令模式（四）
- 請求發送者與接收者解耦——命令模式（五）
- 請求發送者與接收者解耦——命令模式（六）
- 解釋器模式-Interpreter Pattern
- 自定義語言的實現——解釋器模式（一）
- 自定義語言的實現——解釋器模式（二）
- 自定義語言的實現——解釋器模式（三）
- 自定義語言的實現——解釋器模式（四）
- 自定義語言的實現——解釋器模式（五）
- 自定義語言的實現——解釋器模式（六）
- 迭代器模式-Iterator Pattern
- 遍歷聚合對象中的元素——迭代器模式（一）
- 遍歷聚合對象中的元素——迭代器模式（二）
- 遍歷聚合對象中的元素——迭代器模式（三）
- 遍歷聚合對象中的元素——迭代器模式（四）
- 遍歷聚合對象中的元素——迭代器模式（五）
- 遍歷聚合對象中的元素——迭代器模式（六）
- 中介者模式-Mediator Pattern
- 協調多個對象之間的交互——中介者模式（一）
- 協調多個對象之間的交互——中介者模式（二）
- 協調多個對象之間的交互——中介者模式（三）
- 協調多個對象之間的交互——中介者模式（四）
- 協調多個對象之間的交互——中介者模式（五）
- 備忘錄模式-Memento Pattern
- 撤銷功能的實現——備忘錄模式（一）
- 撤銷功能的實現——備忘錄模式（二）
- 撤銷功能的實現——備忘錄模式（三）
- 撤銷功能的實現——備忘錄模式（四）
- 撤銷功能的實現——備忘錄模式（五）
- 觀察者模式-Observer Pattern
- 對象間的聯動——觀察者模式（一）
- 對象間的聯動——觀察者模式（二）
- 對象間的聯動——觀察者模式（三）
- 對象間的聯動——觀察者模式（四）
- 對象間的聯動——觀察者模式（五）
- 對象間的聯動——觀察者模式（六）
- 狀態模式-State Pattern
- 處理對象的多種狀態及其相互轉換——狀態模式（一）
- 處理對象的多種狀態及其相互轉換——狀態模式（二）
- 處理對象的多種狀態及其相互轉換——狀態模式（三）
- 處理對象的多種狀態及其相互轉換——狀態模式（四）
- 處理對象的多種狀態及其相互轉換——狀態模式（五）
- 處理對象的多種狀態及其相互轉換——狀態模式（六）
- 策略模式-Strategy Pattern
- 算法的封裝與切換——策略模式（一）
- 算法的封裝與切換——策略模式（二）
- 算法的封裝與切換——策略模式（三）
- 算法的封裝與切換——策略模式（四）
- 模板方法模式-Template Method Pattern
- 模板方法模式深度解析（一）
- 模板方法模式深度解析（二）
- 模板方法模式深度解析（三）
- 訪問者模式-Visitor Pattern
- 操作復雜對象結構——訪問者模式（一）
- 操作復雜對象結構——訪問者模式（二）
- 操作復雜對象結構——訪問者模式（三）
- 操作復雜對象結構——訪問者模式（四）
- 設計模式趣味學習（復習）
- 設計模式與足球（一）
- 設計模式與足球（二）
- 設計模式與足球（三）
- 設計模式與足球（四）
- 設計模式綜合應用實例
- 多人聯機射擊游戲
- 多人聯機射擊游戲中的設計模式應用（一）
- 多人聯機射擊游戲中的設計模式應用（二）
- 數據庫同步系統
- 設計模式綜合實例分析之數據庫同步系統（一）
- 設計模式綜合實例分析之數據庫同步系統（二）
- 設計模式綜合實例分析之數據庫同步系統（三）