JavaScript設計模式之職責鏈模式詳解

Posted on by

職責鏈模式

職責鏈模式的定義是：使多個對象都有機會處理請求，從而避免請求的發送者和接收者之間的耦合關系，將這些對象連成一條鏈，並沿著這條鏈傳遞該請求，直到有一個對象處理它為止。

職責鏈模式的名字非常形象，一系列可能會處理請求的對象被連接成一條鏈，請求在這些對象之間依次傳遞，直到遇到一個可以處理它的對象，我們把這些對象稱為鏈中的節點，如下圖所示。

1. 現實中的職責鏈模式

職責鏈模式的例子在現實中並不難找到，以下就是常見的跟職責鏈模式有關的場景。

如果早高峰能順利擠上公交車的話，那麼估計這一天都會過得很開心。因為公交車上人實在太多瞭，經常上車後卻找不到售票員在哪，所以隻好把兩塊錢硬幣往前面遞。除非你運氣夠好，站在你前面的第一個人就是售票員，否則，你的硬幣通常要在 N 個人手上傳遞，才能最終到達售票員的手裡。

從這個例子中，我們很容易找到職責鏈模式的最大優點：請求發送者隻需要知道鏈中的第一個節點，從而弱化瞭發送者和一組接收者之間的強聯系。如果不使用職責鏈模式，那麼在公交車上，我就得先搞清楚誰是售票員，才能把硬幣遞給他。

2. 實際開發中的職責鏈模式

假設我們負責一個售賣手機的電商網站，經過分別交納 500 元定金和 200 元定金的兩輪預定後（訂單已在此時生成），現在已經到瞭正式購買的階段。

公司針對支付過定金的用戶有一定的優惠政策。在正式購買後，已經支付過 500 元定金的用戶會收到 100 元的商城優惠券，200 元定金的用戶可以收到 50 元的優惠券，而之前沒有支付定金的用戶隻能進入普通購買模式，也就是沒有優惠券，且在庫存有限的情況下不一定保證能買到。

我們的訂單頁面是 Node 吐出的模板，在頁面加載之初，Node 會傳遞給頁面幾個字段。

  • orderType：表示訂單類型（定金用戶或者普通購買用戶），code 的值為 1 的時候是 500 元定金用戶，為 2 的時候是 200 元定金用戶，為 3 的時候是普通購買用戶。
  • pay：表示用戶是否已經支付定金，值為 true 或者 false, 雖然用戶已經下過 500 元定金的訂單，但如果他一直沒有支付定金，現在隻能降級進入普通購買模式。
  • stock：表示當前用於普通購買的手機庫存數量，已經支付過 500 元或者 200 元定金的用戶不受此限制。

下面我們把這個流程寫成代碼：

const order = function (orderType, pay, stock) {
	if (orderType === 1) { // 500 元定金購買模式
		if (pay === true) { // 已支付定金
			console.log('500 元定金預購, 得到 100 優惠券');
		} else { // 未支付定金，降級到普通購買模式
			if (stock > 0) { // 用於普通購買的手機還有庫存
				console.log('普通購買, 無優惠券');
			} else {
				console.log('手機庫存不足');
			}
		}
	} else if (orderType === 2) { // 200 元定金購買模式
		if (pay === true) {
			console.log('200 元定金預購, 得到 50 優惠券');
		} else {
			if (stock > 0) {
				console.log('普通購買, 無優惠券');
			} else {
				console.log('手機庫存不足');
			}
		}
	} else if (orderType === 3) {
		if (stock > 0) {
			console.log('普通購買, 無優惠券');
		} else {
			console.log('手機庫存不足');
		}
	}
};
order(1, true, 500); // 輸出： 500 元定金預購, 得到 100 優惠券

雖然我們得到瞭意料中的運行結果，但這遠遠算不上一段值得誇獎的代碼。order 函數不僅巨大到難以閱讀，而且需要經常進行修改。雖然目前項目能正常運行，但接下來的維護工作無疑是個夢魘。恐怕隻有最“新手”的程序員才會寫出這樣的代碼。

3. 用職責鏈模式重構代碼

現在我們采用職責鏈模式重構這段代碼，先把 500 元訂單、200 元訂單以及普通購買分成 3 個函數。

接下來把 orderType、pay、stock 這 3 個字段當作參數傳遞給 500 元訂單函數，如果該函數不符合處理條件，則把這個請求傳遞給後面的 200 元訂單函數，如果 200 元訂單函數依然不能處理該請求，則繼續傳遞請求給普通購買函數，代碼如下：

// 500 元訂單
const order500 = function (orderType, pay, stock) {
	if (orderType === 1 && pay === true) {
		console.log('500 元定金預購, 得到 100 優惠券');
	} else {
		order200(orderType, pay, stock); // 將請求傳遞給 200 元訂單
	}
};
// 200 元訂單
const order200 = function (orderType, pay, stock) {
	if (orderType === 2 && pay === true) {
		console.log('200 元定金預購, 得到 50 優惠券');
	} else {
		orderNormal(orderType, pay, stock); // 將請求傳遞給普通訂單
	}
};
// 普通購買訂單
const orderNormal = function (orderType, pay, stock) {
	if (stock > 0) {
		console.log('普通購買, 無優惠券');
	} else {
		console.log('手機庫存不足');
	}
};
// 測試結果：
order500(1, true, 500); // 輸出：500 元定金預購, 得到 100 優惠券
order500(1, false, 500); // 輸出：普通購買, 無優惠券
order500(2, true, 500); // 輸出：200 元定金預購, 得到 500 優惠券
order500(3, false, 500); // 輸出：普通購買, 無優惠券
order500(3, false, 0); // 輸出：手機庫存不足

可以看到，執行結果和前面那個巨大的 order 函數完全一樣，但是代碼的結構已經清晰瞭很多，我們把一個大函數拆分瞭 3 個小函數，去掉瞭許多嵌套的條件分支語句。

目前已經有瞭不小的進步，但我們不會滿足於此，雖然已經把大函數拆分成瞭互不影響的 3 個小函數，但可以看到，請求在鏈條傳遞中的順序非常僵硬，傳遞請求的代碼被耦合在瞭業務函數之中：

const order500 = function (orderType, pay, stock) {
	if (orderType === 1 && pay === true) {
		console.log('500 元定金預購, 得到 100 優惠券');
	} else {
		order200(orderType, pay, stock); // 將請求傳遞給 200 元訂單
		// order200 和 order500 耦合在一起
	}
};

這依然是違反開放—封閉原則的，如果有天我們要增加 300 元預訂或者去掉 200 元預訂，意味著就必須改動這些業務函數內部。就像一根環環相扣打瞭死結的鏈條，如果要增加、拆除或者移動一個節點，就必須得先砸爛這根鏈條。

4. 靈活可拆分的職責鏈節點

本節我們采用一種更靈活的方式，來改進上面的職責鏈模式，目標是讓鏈中的各個節點可以靈活拆分和重組。

首先需要改寫一下分別表示 3 種購買模式的節點函數，我們約定，如果某個節點不能處理請求，則返回一個特定的字符串 'nextSuccessor'來表示該請求需要繼續往後面傳遞：

const order500 = function (orderType, pay, stock) {
	if (orderType === 1 && pay === true) {
		console.log('500 元定金預購，得到 100 優惠券');
	} else {
		return 'nextSuccessor'; // 我不知道下一個節點是誰，反正把請求往後面傳遞
	}
};
const order200 = function (orderType, pay, stock) {
	if (orderType === 2 && pay === true) {
		console.log('200 元定金預購，得到 50 優惠券');
	} else {
		return 'nextSuccessor'; // 我不知道下一個節點是誰，反正把請求往後面傳遞
	}
};
const orderNormal = function (orderType, pay, stock) {
	if (stock > 0) {
		console.log('普通購買，無優惠券');
	} else {
		console.log('手機庫存不足');
	}
};

接下來需要把函數包裝進職責鏈節點，我們定義一個構造函數 Chain，在 new Chain 的時候傳 遞的參數即為需要被包裝的函數，同時它還擁有一個實例屬性 this.successor，表示在鏈中的下 一個節點。

此外 Chain 的 prototype 中還有兩個函數，它們的作用如下所示：

// Chain.prototype.setNextSuccessor 指定在鏈中的下一個節點
// Chain.prototype.passRequest 傳遞請求給某個節點
const Chain = function (fn) {
	this.fn = fn;
	this.successor = null;
};
Chain.prototype.setNextSuccessor = function (successor) {
	return this.successor = successor;
};
Chain.prototype.passRequest = function () {
	const ret = this.fn.apply(this, arguments);
	if (ret === 'nextSuccessor') {
		return this.successor && this.successor.passRequest.apply(this.successor, arguments);
	}
	return ret;
};

現在我們把 3 個訂單函數分別包裝成職責鏈的節點：

const chainOrder500 = new Chain(order500);
const chainOrder200 = new Chain(order200);
const chainOrderNormal = new Chain(orderNormal);

然後指定節點在職責鏈中的順序：

chainOrder500.setNextSuccessor(chainOrder200);
chainOrder200.setNextSuccessor(chainOrderNormal);

最後把請求傳遞給第一個節點：

chainOrder500.passRequest(1, true, 500); // 輸出：500 元定金預購，得到 100 優惠券
chainOrder500.passRequest(2, true, 500); // 輸出：200 元定金預購，得到 50 優惠券
chainOrder500.passRequest(3, true, 500); // 輸出：普通購買，無優惠券
chainOrder500.passRequest(1, false, 0); // 輸出：手機庫存不足

通過改進，我們可以自由靈活地增加、移除和修改鏈中的節點順序，假如某天網站運營人員又想出瞭支持 300 元定金購買，那我們就在該鏈中增加一個節點即可：

const order300 = function () {
	// 具體實現略 
};
const chainOrder300 = new Chain(order300);
chainOrder500.setNextSuccessor(chainOrder300);
chainOrder300.setNextSuccessor(chainOrder200);

對於程序員來說，我們總是喜歡去改動那些相對容易改動的地方，就像改動框架的配置文件遠比改動框架的源代碼簡單得多。在這裡完全不用理會原來的訂單函數代碼，我們要做的隻是增加一個節點，然後重新設置鏈中相關節點的順序。

5. 異步的職責鏈

在上一節的職責鏈模式中，我們讓每個節點函數同步返回一個特定的值"nextSuccessor"，來表示是否把請求傳遞給下一個節點。而在現實開發中，我們經常會遇到一些異步的問題，比如我們要在節點函數中發起一個 ajax異步請求，異步請求返回的結果才能決定是否繼續在職責鏈中 passRequest。

這時候讓節點函數同步返回"nextSuccessor"已經沒有意義瞭，所以要給 Chain 類再增加一個原型方法 Chain.prototype.next，表示手動傳遞請求給職責鏈中的下一個節點：

Chain.prototype.next = function () {
	return this.successor && this.successor.passRequest.apply(this.successor, arguments);
};

來看一個異步職責鏈的例子：

const fn1 = new Chain(function () {
	console.log(1);
	return 'nextSuccessor';
});
const fn2 = new Chain(function () {
	console.log(2);
	setTimeout(() => {
		this.next();
	}, 1000);
});
const fn3 = new Chain(function () {
	console.log(3);
});
fn1.setNextSuccessor(fn2).setNextSuccessor(fn3);
fn1.passRequest();

現在我們得到瞭一個特殊的鏈條，請求在鏈中的節點裡傳遞，但節點有權利決定什麼時候把請求交給下一個節點。可以想象，異步的職責鏈加上命令模式（把 ajax 請求封裝成命令對象），我們可以很方便地創建一個異步 ajax 隊列庫。

6. 職責鏈模式的優缺點

前面已經說過，職責鏈模式的最大優點就是解耦瞭請求發送者和 N 個接收者之間的復雜關系，由於不知道鏈中的哪個節點可以處理你發出的請求，所以你隻需把請求傳遞給第一個節點即可，如下圖所示。

用職責鏈模式改進後：

在手機商城的例子中，本來我們要被迫維護一個充斥著條件分支語句的巨大的函數，在例子裡的購買過程中隻打印瞭一條 log 語句。其實在現實開發中，這裡要做更多事情，比如根據訂單種類彈出不同的浮層提示、渲染不同的 UI 節點、組合不同的參數發送給不同的 cgi 等。用瞭職責鏈模式之後，每種訂單都有各自的處理函數而互不影響。

其次，使用瞭職責鏈模式之後，鏈中的節點對象可以靈活地拆分重組。增加或者刪除一個節點，或者改變節點在鏈中的位置都是輕而易舉的事情。這一點我們也已經看到，在上面的例子中，增加一種訂單完全不需要改動其他訂單函數中的代碼。

職責鏈模式還有一個優點，那就是可以手動指定起始節點，請求並不是非得從鏈中的第一個節點開始傳遞。比如在公交車的例子中，如果我明確在我前面的第一個人不是售票員，那我當然可以越過他把公交卡遞給他前面的人，這樣可以減少請求在鏈中的傳遞次數，更快地找到合適的請求接受者。這在普通的條件分支語句下是做不到的，我們沒有辦法讓請求越過某一個 if 判斷。

拿代碼來證明這一點，假設某一天網站中支付過定金的訂單已經全部結束購買流程，我們在接下來的時間裡隻需要處理普通購買訂單，所以我們可以直接把請求交給普通購買訂單節點：

orderNormal.passRequest(1, false, 500); // 普通購買, 無優惠券

如果運用得當，職責鏈模式可以很好地幫助我們組織代碼，但這種模式也並非沒有弊端，首先我們不能保證某個請求一定會被鏈中的節點處理。此時的請求就得不到答復，而是徑直從鏈尾離開，或者拋出一個錯誤異常。在這種情況下，我們可以在鏈尾增加一個保底的接受者節點來處理這種即將離開鏈尾的請求。

另外，職責鏈模式使得程序中多瞭一些節點對象，可能在某一次的請求傳遞過程中，大部分節點並沒有起到實質性的作用，它們的作用僅僅是讓請求傳遞下去，從性能方面考慮，我們要避免過長的職責鏈帶來的性能損耗。

7. 用 AOP 實現職責鏈

在之前的職責鏈實現中，我們利用瞭一個 Chain 類來把普通函數包裝成職責鏈的節點。其實利用 JavaScript 的函數式特性，有一種更加方便的方法來創建職責鏈。

下面我們改寫一下之前的 Function.prototype.after 函數，使得第一個函數返回'nextSuccessor' 時，將請求繼續傳遞給下一個函數，無論是返回字符串'nextSuccessor'或者 false 都隻是一個約定，當然在這裡我們也可以讓函數返回 false 表示傳遞請求，選擇'nextSuccessor'字符串是因為它看起來更能表達我們的目的，代碼如下：

Function.prototype.after = function (fn) {
	const self = this;
	return function () {
		const ret = self.apply(this, arguments);
		if (ret === 'nextSuccessor') {
			return fn.apply(this, arguments);
		}
		return ret;
	}
};
const order = order500yuan.after(order200yuan).after(orderNormal);
order(1, true, 500); // 輸出：500 元定金預購，得到 100 優惠券
order(2, true, 500); // 輸出：200 元定金預購，得到 50 優惠券
order(1, false, 500); // 輸出：普通購買，無優惠券

用 AOP 來實現職責鏈既簡單又巧妙，但這種把函數疊在一起的方式，同時也疊加瞭函數的作用域，如果鏈條太長的話，也會對性能有較大的影響。

8. 小結

在 JavaScript 開發中，職責鏈模式是最容易被忽視的模式之一。實際上隻要運用得當，職責鏈模式可以很好地幫助我們管理代碼，降低發起請求的對象和處理請求的對象之間的耦合性。職責鏈中的節點數量和順序是可以自由變化的，我們可以在運行時決定鏈中包含哪些節點。

無論是作用域鏈、原型鏈，還是 DOM 節點中的事件冒泡，我們都能從中找到職責鏈模式的影子。職責鏈模式還可以和組合模式結合在一起，用來連接部件和父部件，或是提高組合對象的效率。學會使用職責鏈模式，相信在以後的代碼編寫中，將會對你大有裨益。

到此這篇關於JavaScript設計模式之職責鏈模式詳解的文章就介紹到這瞭,更多相關JS職責鏈模式內容請搜索WalkonNet以前的文章或繼續瀏覽下面的相關文章希望大傢以後多多支持WalkonNet！

推薦閱讀：