Class field declarations for JavaScript（JavaScript 類的字段聲明）目前已經(jīng)進(jìn)入了 stage-3，其中包含一項 OOP 開發(fā)者都很關(guān)注的內(nèi)容：Private fields。JavaScript 一直沒有私有成員并不是沒有原因，所以這一提議給 JavaScript 帶來了新的挑戰(zhàn)。但同時，JavaScript 在 ES2015 發(fā)布的時候已經(jīng)在考慮私有化的問題了，所以要實現(xiàn)私有成員也并非毫無基礎(chǔ)。

坑

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

代表將 _ 前綴約定為私有

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() 來進(jìn)行各層次應(yīng)該負(fù)責(zé)的布局任務(wù)。但理想和現(xiàn)實總是有差距的，在 JavaScript 中運行就會發(fā)現(xiàn) BusinessView._layoutMap() 被執(zhí)行了兩次，而 MapView._layoutMap() 未執(zhí)行。為什么？

虛函數(shù)

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

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

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

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

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