JavaScript最少知識原則與體現是什么

今天小編給大家分享一下JavaScript最少知識原則與體現是什么的相關知識點，內容詳細，邏輯清晰，相信大部分人都還太了解這方面的知識，所以分享這篇文章給大家參考一下，希望大家閱讀完這篇文章后有所收獲，下面我們一起來了解一下吧。

1. 減少對象之間的聯系

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

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

2. 設計模式中的最少知識原則

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

中介者模式

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

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

外觀模式

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

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

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

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

最簡單的外觀模式應該是類似下面的代碼：

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

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

• 為一組子系統提供一個簡單便利的訪問入口。

• 隔離客戶與復雜子系統之間的聯系，客戶不用去了解子系統的細節。

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

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

3. 封裝在最少知識原則中的體現

封裝在很大程度上表達的是數據的隱藏。一個模塊或者對象可以將內部的數據或者實現細節隱藏起來，只暴露必要的接口 API 供外界訪問。對象之間難免產生聯系，當一個對象必須引用另外一個對象的時候，我們可以讓對象只暴露必要的接口，讓對象之間的聯系限制在最小的范圍之內。

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

• 變量在全局聲明，或者在代碼的任何位置隱式申明（不用 var），則該變量在全局可見；

• 變量在函數內顯式申明（使用 var），則在函數內可見。

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

假設我們要編寫一個具有緩存效果的計算乘積的函數 function mult (){}，我們需要一個對象 const cache = {}來保存已經計算過的結果。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

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

以上就是“JavaScript最少知識原則與體現是什么”這篇文章的所有內容，感謝各位的閱讀！相信大家閱讀完這篇文章都有很大的收獲，小編每天都會為大家更新不同的知識，如果還想學習更多的知識，請關注億速云行業資訊頻道。