坑

首先挖個坑 —— 這是一段 JS 代碼，BusinessView 中要干兩件事情，即對表單和地圖進行布局。

代表將 _ 前綴約定為私有

class BaseView {
layout() {
console.log("BaseView Layout");
}
}
class BusinessView extends BaseView {
layout() {
super.layout();
this._layoutForm();
this._layoutMap();
}
_layoutForm() {
// ....
}
_layoutMap() {
// ....
}
}

然后，由于業(yè)務(wù)的發(fā)展，發(fā)現(xiàn)有很多視圖都存在地圖布局。這里選用繼承的方式來實現(xiàn)，所以從 BusinessView 中把地圖相關(guān)的內(nèi)容抽象成一個基類叫 MapView：

class MapView extends BaseView {
layout() {
super.layout();
this._layoutMap();
}
_layoutMap() {
console.log("MapView layout map");
}
}
class BusinessView extends MapView {
layout() {
super.layout();
this._layoutForm();
this._layoutMap();
}
_layoutForm() {
// ....
}
_layoutMap() {
console.log("BusinessView layout map");
}
}

上面這兩段代碼是很典型的基于繼承的 OOP 思想，本意是期望各個層次的類都可以通過 layout() 來進行各層次應(yīng)該負責的布局任務(wù)。但理想和現(xiàn)實總是有差距的，在 JavaScript 中運行就會發(fā)現(xiàn) BusinessView._layoutMap() 被執(zhí)行了兩次，而 MapView._layoutMap() 未執(zhí)行。為什么？

虛函數(shù)

JavaScript 中如果在祖先和子孫類中定義了相同的名稱的方法，默認會調(diào)用子孫類中的這個方法。如果想調(diào)用祖先類中的同名方法，需要在子孫類中通過 super. 來調(diào)用。

這里可以分析一下這個過程：

在子類創(chuàng)建對象的時候，其類和所有祖先類的定義都已經(jīng)加載了。這個時候

• 調(diào)用 BusinessView.layout()
• 找到 super.layout()，開始調(diào)用 MapView.layout()
• MapView.layout() 中調(diào)用this._layoutMap()
  • 于是從當前對象（BusinessView 對象）尋找 _layoutMap()
  • 找到，調(diào)用它

你看，由于 BusinessView 定義了 _layoutMap，所以壓根都沒去搜索原型鏈。對的，這是基于原型關(guān)系的 OOP 的局限。如果我們看看 C# 的處理過程，就會發(fā)現(xiàn)有所不同

• 調(diào)用 BusinessView.layout()
• 找到 base.layout()，開始調(diào)用 MapView.layout()
• MapView.layout() 中調(diào)用 this._layoutMap()
  • 在 MapView 中找到 _layoutMap()
  • 檢查是否虛函數(shù)
    • 如果是，往子類找到最后一個重載（override）函數(shù)，調(diào)用
    • 如果不是，直接調(diào)用

發(fā)現(xiàn)區(qū)別了嗎？關(guān)鍵是在于判斷“虛函數(shù)”。

然而，這跟私有成員又有什么關(guān)系呢？因為私有函數(shù)肯定不是虛函數(shù)，所以在 C# 中，如果將 _layoutMap 定義為私有，那 MapView.layout() 調(diào)用的就一定是 MapView._layoutMap()。

虛函數(shù)的概念有點小復(fù)雜。不過可以簡單理解為，如果一個成員方法被聲明為虛函數(shù)，在調(diào)用的時候就會延著其虛函數(shù)鏈找到最后的重載來進行調(diào)用。

JavaScript 中雖然約定 _ 前綴的是私有，那也只是君子之約，它實質(zhì)上仍然不是私有。君子之約對人有效，計算機又不知道你有這個約定……。但是，如果 JavaScript 真的實現(xiàn)了私有成員，那么計算機就知道了，_layoutMap() 是個私有方法，應(yīng)該調(diào)用本類中的定義，而不是去尋找子類中的定義。

解決當下的私有化問題

JavaScript 當下沒有私有成員，但是我們又需要切時有效地解決私有成員問題，怎么辦？當然有辦法，用 Symbol 和閉包來解決。

注意，這里的閉包不是指導(dǎo)在函數(shù)函數(shù)中生成閉包，請繼續(xù)往下看

首先搞清楚，我們變通的看待這個私有化問題 —— 就是讓祖先類調(diào)用者在調(diào)用某個方法的時候，它不會先去子類中尋找。這個問題從語法上解決不了，JavaScript 就是要從具體的實例從后往前去尋找指定名稱的方法。但是，如果找不到這個方法名呢？

之所以能找到，因為方法名是字符串。一個字符串在全局作用域內(nèi)都表示著同樣的意義。但是 ES2015 帶來了 Symbol，它必須實例化，而且每次實例化出來一定代表著不同的標識 —— 如果我們將類定義在一個閉包中，在這個閉包中聲明一個 Symbol，用它來作為私有成員的名稱，問題就解決了，比如

const MapView = (() => {
const _layoutMap = Symbol();
return class MapView extends BaseView {
layout() {
super.layout();
this[_layoutMap]();
}
[_layoutMap]() {
console.log("MapView layout map");
}
}
})();
const BusinessView = (() => {
const _layoutForm = Symbol();
const _layoutMap = Symbol();
return class BusinessView extends MapView {
layout() {
super.layout();
this[_layoutForm]();
this[_layoutMap]();
}
[_layoutForm]() {
// ....
}
[_layoutMap]() {
console.log("BusinessView layout map");
}
}
})();

而現(xiàn)代基于模塊的定義，甚至連閉包都可以省了（模塊系統(tǒng)會自動封閉作用域）

const _layoutMap = Symbol();
export class MapView extends BaseView {
layout() {
super.layout();
this[_layoutMap]();
}
[_layoutMap]() {
console.log("MapView layout map");
}
}
const _layoutForm = Symbol();
const _layoutMap = Symbol();
export class BusinessView extends MapView {
layout() {
super.layout();
this[_layoutForm]();
this[_layoutMap]();
}
[_layoutForm]() {
// ....
}
[_layoutMap]() {
console.log("BusinessView layout map");
}
}

改革過后的代碼就可以按預(yù)期輸出了：

BaseView Layout
MapView layout map
BusinessView layout map

后記

筆者在多年開發(fā)過程中養(yǎng)成了分析和解決問題的一系列思維習慣，所以常?？梢匝杆俚耐高^現(xiàn)象看到需要解決的實質(zhì)性問題，并基于現(xiàn)有條件來解決它。確實，Symbol 出現(xiàn)的理由之一就是解決私有化問題，但是為什么要用以及怎么用就需要去分析和思考了。

以上就是本文的全部內(nèi)容，希望對大家的學習有所幫助，也希望大家多多支持腳本之家。

最新評論