1. 減少對象之間的聯(lián)系

單一職責(zé)原則指導(dǎo)我們把對象劃分成較小的粒度，這可以提高對象的可復(fù)用性。但越來越多的對象之間可能會產(chǎn)生錯綜復(fù)雜的聯(lián)系，如果修改了其中一個對象，很可能會影響到跟它相互引用的其他對象。對象和對象耦合在一起，有可能會降低它們的可復(fù)用性。在程序中，對象的“朋友”太多并不是一件好事，“城門失火，殃及池魚”和“一人犯法，株連九族”的故事時有發(fā)生。

最少知識原則要求我們在設(shè)計程序時，應(yīng)當(dāng)盡量減少對象之間的交互。如果兩個對象之間不必彼此直接通信，那么這兩個對象就不要發(fā)生直接的相互聯(lián)系。常見的做法是引入一個第三者對象，來承擔(dān)這些對象之間的通信作用。如果一些對象需要向另一些對象發(fā)起請求，可以通過第三者對象來轉(zhuǎn)發(fā)這些請求。

2. 設(shè)計模式中的最少知識原則

最少知識原則在設(shè)計模式中體現(xiàn)得最多的地方是中介者模式和外觀模式，下面我們分別進(jìn)行介紹。

中介者模式

在世界杯期間購買足球彩票，如果沒有博彩公司作為中介，上千萬的人一起計算賠率和輸贏絕對是不可能的事情。博彩公司作為中介，每個人都只和博彩公司發(fā)生關(guān)聯(lián)，博彩公司會根據(jù)所有人的投注情況計算好賠率，彩民們贏了錢就從博彩公司拿，輸了錢就賠給博彩公司。

中介者模式很好地體現(xiàn)了最少知識原則。通過增加一個中介者對象，讓所有的相關(guān)對象都通過中介者對象來通信，而不是互相引用。所以，當(dāng)一個對象發(fā)生改變時，只需要通知中介者對象即可。

外觀模式

外觀模式在 JavaScript 中的使用場景并不多。外觀模式主要是為子系統(tǒng)中的一組接口提供一個一致的界面，外觀模式定義了一個高層接口，這個接口使子系統(tǒng)更加容易使用。

外觀模式的作用是對客戶屏蔽一組子系統(tǒng)的復(fù)雜性。外觀模式對客戶提供一個簡單易用的高層接口，高層接口會把客戶的請求轉(zhuǎn)發(fā)給子系統(tǒng)來完成具體的功能實現(xiàn)。大多數(shù)客戶都可以通過請求外觀接口來達(dá)到訪問子系統(tǒng)的目的。但在一段使用了外觀模式的程序中，請求外觀并不是強制的。如果外觀不能滿足客戶的個性化需求，那么客戶也可以選擇越過外觀來直接訪問子系統(tǒng)。

拿全自動洗衣機的一鍵洗衣按鈕舉例，這個一鍵洗衣按鈕就是一個外觀。如果是老式洗衣機，客戶要手動選擇浸泡、洗衣、漂洗、脫水這 4 個步驟。如果這種洗衣機被淘汰了，新式洗衣機的漂洗方式發(fā)生了改變，那我們還得學(xué)習(xí)新的漂洗方式。而全自動洗衣機的好處很明顯，不管洗衣機內(nèi)部如何進(jìn)化，客戶要操作的，始終只是一個一鍵洗衣的按鈕。這個按鈕就是為一組子系統(tǒng)所創(chuàng)建的外觀。但如果一鍵洗衣程序設(shè)定的默認(rèn)漂洗時間是 20 分鐘，而客戶希望這個漂洗時間是 30 分鐘，那么客戶自然可以選擇越過一鍵洗衣程序，自己手動來控制這些“子系統(tǒng)”運轉(zhuǎn)。

外觀模式容易跟普通的封裝實現(xiàn)混淆。這兩者都封裝了一些事物，但外觀模式的關(guān)鍵是定義一個高層接口去封裝一組“子系統(tǒng)”。子系統(tǒng)在 C++或者 Java 中指的是一組類的集合，這些類相互協(xié)作可以組成系統(tǒng)中一個相對獨立的部分。在 JavaScript 中我們通常不會過多地考慮“類”，如果將外觀模式映射到 JavaScript 中，這個子系統(tǒng)至少應(yīng)該指的是一組函數(shù)的集合。

最簡單的外觀模式應(yīng)該是類似下面的代碼：

const A = function () {
	a1();
	a2();
}
const B = function () {
	b1();
	b2();
}
const facade = function () {
	A();
	B();
}
facade();

現(xiàn)在再來看看外觀模式和最少知識原則之間的關(guān)系。外觀模式的作用主要有兩點。

• 為一組子系統(tǒng)提供一個簡單便利的訪問入口。
• 隔離客戶與復(fù)雜子系統(tǒng)之間的聯(lián)系，客戶不用去了解子系統(tǒng)的細(xì)節(jié)。

從第二點來，外觀模式是符合最少知識原則的。比如全自動洗衣機的一鍵洗衣按鈕，隔開了客戶和浸泡、洗衣、漂洗、脫水這些子系統(tǒng)的直接聯(lián)系，客戶不用去了解這些子系統(tǒng)的具體實現(xiàn)。

假設(shè)我們在編寫這個老式洗衣機的程序，客戶至少要和浸泡、洗衣、漂洗、脫水這 4 個子系統(tǒng)打交道。如果其中的一個子系統(tǒng)發(fā)生了改變，那么客戶的調(diào)用代碼就得發(fā)生改變。而通過外觀將客戶和這些子系統(tǒng)隔開之后，如果修改子系統(tǒng)內(nèi)部，只要外觀不變，就不會影響客戶的調(diào)用。同樣，對外觀的修改也不會影響到子系統(tǒng)，它們可以分別變化而互不影響。

3. 封裝在最少知識原則中的體現(xiàn)

封裝在很大程度上表達(dá)的是數(shù)據(jù)的隱藏。一個模塊或者對象可以將內(nèi)部的數(shù)據(jù)或者實現(xiàn)細(xì)節(jié)隱藏起來，只暴露必要的接口 API 供外界訪問。對象之間難免產(chǎn)生聯(lián)系，當(dāng)一個對象必須引用另外一個對象的時候，我們可以讓對象只暴露必要的接口，讓對象之間的聯(lián)系限制在最小的范圍之內(nèi)。

同時，封裝也用來限制變量的作用域。在 JavaScript 中對變量作用域的規(guī)定是：

• 變量在全局聲明，或者在代碼的任何位置隱式申明（不用 var），則該變量在全局可見；
• 變量在函數(shù)內(nèi)顯式申明（使用 var），則在函數(shù)內(nèi)可見。

把變量的可見性限制在一個盡可能小的范圍內(nèi)，這個變量對其他不相關(guān)模塊的影響就越小，變量被改寫和發(fā)生沖突的機會也越小。這也是廣義的最少知識原則的一種體現(xiàn)。

假設(shè)我們要編寫一個具有緩存效果的計算乘積的函數(shù) function mult (){}，我們需要一個對象 const cache = {}來保存已經(jīng)計算過的結(jié)果。cache 對象顯然只對 mult 有用，把 cache 對象放在 mult 形成的閉包中，顯然比把它放在全局作用域更加合適，代碼如下：

const mult = (function () {
	const cache = {};
	return function () {
		const args = Array.prototype.join.call(arguments, ',');
		if (cache[args]) {
			return cache[args];
		}
		let a = 1;
		for (let i = 0, l = arguments.length; i < l; i++) {
			a = a * arguments[i];
		}
		return cache[args] = a;
	}
})();
mult(1, 2, 3); // 輸出： 6 

雖然遵守最小知識原則減少了對象之間的依賴，但也有可能增加一些龐大到難以維護(hù)的第三者對象。跟單一職責(zé)原則一樣，在實際開發(fā)中，是否選擇讓代碼符合最少知識原則，要根據(jù)具體的環(huán)境來定。

到此這篇關(guān)于JavaScript最少知識原則介紹與體現(xiàn)的文章就介紹到這了,更多相關(guān)JS最少知識原則內(nèi)容請搜索腳本之家以前的文章或繼續(xù)瀏覽下面的相關(guān)文章希望大家以后多多支持腳本之家！

最新評論