程序員必知的23種設計模式之職責鏈模式

1. 模式引出–OA系統採購審批需求

學校OA系統的採購審批項目:需求是

  1. 採購員採購教學器材

  2. 如果金額 小於等於5000, 由教學主任審批 (0<=x<=5000)

  3. 如果金額 小於等於10000, 由院長審批 (5000<x<=10000)

  4. 如果金額 小於等於30000, 由副校長審批 (10000<x<=30000)

  5. 如果金額 超過30000以上,有校長審批 ( 30000<x)

請設計程序完成採購審批項目

2. 傳統方案解決OA系統審批

  1. 構造一個請求類,和每一個具體的審批者類
  2. 在請求類中通過if-else判斷,然後調用對應的審批者執行操作

在這裏插入圖片描述

3. 傳統方案解決OA系統審批問題分析

  1. 傳統方式是:接收到一個採購請求後,根據採購金額來調用對應的Approver (審批人)完成審批。

  2. 傳統方式的問題分析 : 客戶端這裏會使用到 分支判斷(比如 switch) 來對不同的採購請求處理, 這樣就存在如下問題 (1) 如果各個級別的人員審批金額髮生變化,在客戶端的也需要變化 (2) 客戶端必須明確的知道 有多少個審批級別和訪問

  3. 這樣 對一個採購請求進行處理 和 Approver (審批人) 就存在強耦合關係,不利於代碼的擴展和維護

  4. 解決方案 =》 職責鏈模式

4. 職責鏈模式基本介紹

  1. 職責鏈模式(Chain of Responsibility Pattern), 又叫 責任鏈模式,爲請求創建了一個接收者對象的鏈(簡單示意圖)。這種模式對請求的發送者和接收者進行解耦。

  2. 職責鏈模式通常每個接收者都包含對另一個接收者的引用。如果一個對象不能處理該請求,那麼它會把相同的請求傳給下一個接收者,依此類推。

  3. 這種類型的設計模式屬於行爲型模式
    在這裏插入圖片描述

4.1 職責鏈模式的原理類圖

在這裏插入圖片描述

職責鏈模式(Chain Of Responsibility),使多個對象都有機會處理請求,從而避免請求的發送者和接收者之間的耦合關

系。將這個對象連成一條鏈,並沿着這條鏈傳遞該請求,直到有一個對象處理它爲止.

4.2 對原理類圖的說明-即(職責鏈模式的角色及職責)
  1. Handler : 抽象的處理者, 定義了一個處理請求的接口, 同時含義另外Handler

  2. ConcreteHandlerA , B 是具體的處理者, 處理它自己負責的請求, 可以訪問它的後繼者(即下一個處理者), 如果可以處理當前請求,則處理,否則就將該請求交個 後繼者去處理,從而形成一個職責鏈

  3. Request , 含義很多屬性,表示一個請求

5. 案例修改

UML類圖

在這裏插入圖片描述

Approver.java

// 處理者接口
public abstract class Approver {

	// 下一個處理者
	public Approver approver;

	public void setApprover(Approver approver) {
		this.approver = approver;
	}

	
	// 處理方法
	public abstract void processRequest(PurchaseRequest purchaseRequest);

}

CollegeApprover.java

// 具體處理者
public class CollegeApprover extends Approver {

	@Override
	public void processRequest(PurchaseRequest purchaseRequest) {
		if (purchaseRequest.getPrice() > 5000 && purchaseRequest.getPrice() <= 10000) {
			System.out.println("請求被 CollegeApprover 處理了");
		} else {
			// 交給下一個處理
			if (approver != null)
				approver.processRequest(purchaseRequest);
			else {
				System.out.println("請求沒有被處理");
			}
		}
	}

}

DepartmentApprover.java

// 具體處理者
public class DepartmentApprover extends Approver {

	@Override
	public void processRequest(PurchaseRequest purchaseRequest) {
		if (purchaseRequest.getPrice() <= 5000) {
			System.out.println("請求被 DepartmentApprover 處理了");
		} else {
			// 交給下一個處理
			if (approver != null)
				approver.processRequest(purchaseRequest);
			else {
				System.out.println("請求沒有被處理");
			}
		}
	}

}

PurchaseRequest.java

// 請求類
public class PurchaseRequest {
	private float price = 0.0f;

	public PurchaseRequest(float price) {
		this.price = price;
	}

	public float getPrice() {
		return price;
	}

	public void setPrice(float price) {
		this.price = price;
	}

}

SchoolMasterApprover.java

// 具體處理者
public class SchoolMasterApprover extends Approver {

	@Override
	public void processRequest(PurchaseRequest purchaseRequest) {
		if (purchaseRequest.getPrice() > 30000) {
			System.out.println("請求被 SchoolMasterApprover 處理了");
		} else {
			// 交給下一個處理
			if (approver != null)
				approver.processRequest(purchaseRequest);
			else {
				System.out.println("請求沒有被處理");
			}
		}
	}

}

ViceSchoolMasterApprover.java

// 具體處理者
public class ViceSchoolMasterApprover extends Approver {

	@Override
	public void processRequest(PurchaseRequest purchaseRequest) {
		if (purchaseRequest.getPrice() > 10000 && purchaseRequest.getPrice() <= 30000) {
			System.out.println("請求被 ViceSchoolMasterApprover 處理了");
		} else {
			// 交給下一個處理
			if (approver != null)
				approver.processRequest(purchaseRequest);
			else {
				System.out.println("請求沒有被處理");
			}
		}
	}

}

測試Main.java

public class Main {
	public static void main(String[] args) {
		PurchaseRequest request = new PurchaseRequest(6000);
		
		DepartmentApprover departmentApprover = new DepartmentApprover();
		CollegeApprover collegeApprover = new CollegeApprover();
		ViceSchoolMasterApprover viceSchoolMasterApprover = new ViceSchoolMasterApprover();
		SchoolMasterApprover schoolMasterApprover = new SchoolMasterApprover();
		
		// 設置成一個環狀,因爲已經有處理數字的所有範圍,所以不會有死循環
		departmentApprover.setApprover(collegeApprover);
		collegeApprover.setApprover(viceSchoolMasterApprover);
		viceSchoolMasterApprover.setApprover(schoolMasterApprover);
		schoolMasterApprover.setApprover(departmentApprover);
		
		
		// 然後可以從任意一個處理者開始傳遞請求
//		departmentApprover.processRequest(request);
		viceSchoolMasterApprover.processRequest(request);
	}
}

輸出結果

在這裏插入圖片描述

6. 職責鏈模式的注意事項和細節

  1. 將請求和處理分開,實現解耦,提高系統的靈活性

  2. 簡化了對象,使對象不需要知道鏈的結構

  3. 性能會受到影響,特別是在鏈比較長的時候,因此需控制鏈中最大節點數量,一般通過在Handler中設置一個最大節點數量,在setNext()方法中判斷是否已經超過閥值,超過則不允許該鏈建立,避免出現超長鏈無意識地破壞系統性能

  4. 調試不方便。採用了類似遞歸的方式,調試時邏輯可能比較複雜

  5. 最佳應用場景:有多個對象可以處理同一個請求時,比如:多級請求、請假/加薪等審批流程、Java Web中Tomcat對Encoding的處理、攔截器

發表評論
所有評論
還沒有人評論,想成為第一個評論的人麼? 請在上方評論欄輸入並且點擊發布.
相關文章