JavaScript 私人成員

標籤：載入   欄位   相關   return   計算   怎麼   從後往前   stage   基礎   

Class field declarations for JavaScript（JavaScript 類的欄位聲明）目前已經進入了 stage-3，其中包含一項 OOP 開發人員都很關注的內容：Private fields。JavaScript 一直沒有私人成員並不是沒有原因，所以這一提議給 JavaScript 帶來了新的挑戰。但同時，JavaScript 在 ES2015 發布的時候已經在考慮私人化的問題了，所以要實現私人成員也並非毫無基礎。

筆者在專欄《JavaScript 全棧工程師養成記》的第四章講到了原型 OOP 關係和繼承 OOP 關係的關鍵區別。今天這裡就研究一下 JavaScript 私人成員的問題。

坑

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

代表將 _ 首碼約定為私人

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

然後，由於業務的發展，發現有很多視圖都存在地圖布局。這裡選用繼承的方式來實現，所以從 BusinessView 中把地圖相關的內容抽象成一個基類叫 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() 來進行各層次應該負責的布局任務。但理想和現實總是有差距的，在 JavaScript 中運行就會發現 BusinessView._layoutMap() 被執行了兩次，而 MapView._layoutMap() 未執行。為什嗎？

虛函數

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

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

在子類建立對象的時候，其類和所有祖先類的定義都已經載入了。這個時候

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

你看，由於 BusinessView 定義了 _layoutMap，所以壓根都沒去搜尋原型鏈。對的，這是基於原型關係的 OOP 的局限。如果我們看看 C# 的處理過程，就會發現有所不同

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

發現區別了嗎？關鍵是在於判斷“虛函數”。

然而，這跟私人成員又有什麼關係呢？因為私人函數肯定不是虛函數，所以在 C# 中，如果將 _layoutMap 定義為私人，那 MapView.layout() 調用的就一定是 MapView._layoutMap()。

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

JavaScript 中雖然約定 _ 首碼的是私人，那也只是君子之約，它實質上仍然不是私人。君子之約對人有效，電腦又不知道你有這個約定……。但是，如果 JavaScript 真的實現了私人成員，那麼電腦就知道了，_layoutMap() 是個私人方法，應該調用本類中的定義，而不是去尋找子類中的定義。

解決當下的私人化問題

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

注意，這裡的閉包不是指導在函數函數中產生閉包，請繼續往下看

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

之所以能找到，因為方法名是字串。一個字串在全域範圍內都表示著同樣的意義。但是 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");        }    }})();

而現代基於模組的定義，甚至連閉包都可以省了（模組系統會自動封閉範圍）

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");    }}

改革過後的代碼就可以按預期輸出了：

BaseView LayoutMapView layout mapBusinessView layout map

後記

筆者在多年開發過程中養成了分析和解決問題的一系列思維習慣，所以常常可以迅速的透過現象看到需要解決的實質性問題，並基於現有條件來解決它。確實，Symbol 出現的理由之一就是解決私人化問題，但是為什麼要用以及怎麼用就需要去分析和思考了。

學習可以讓人解決相同的問題，但思考可以讓人解決相似的問題。歡迎讀者們來學習筆者的專欄《JavaScript 全棧工程師養成記》，並跟著筆者一起思考、分析和解決軟體開發過程中的若干問題。

JavaScript 私人成員