JavaScript 私有成員

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 Layout
MapView layout map
BusinessView layout map

後記

筆者在多年開發過程當中養成了分析和解決問題的一系列思惟習慣，因此經常能夠迅速的透過現象看到須要解決的實質性問題，並基於現有條件來解決它。確實，Symbol 出現的理由之一就是解決私有化問題，可是爲何要用以及怎麼用就須要去分析和思考了。

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