Class field declarations for JavaScript(JavaScript 類的字段聲明)目前已經進入了 stage-3,其中包含一項 OOP 開發者都很關注的內容:Private fields。JavaScript 一直沒有私有成員并不是沒有原因,所以這一提議給 JavaScript 帶來了新的挑戰。但同時,JavaScript 在 ES2015 發布的時候已經在考慮私有化的問題了,所以要實現私有成員也并非毫無基礎。
坑
首先挖個坑 ―― 這是一段 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 定義了 _layoutMap,所以壓根都沒去搜索原型鏈。對的,這是基于原型關系的 OOP 的局限。如果我們看看 C# 的處理過程,就會發現有所不同
發現區別了嗎?關鍵是在于判斷“虛函數”。
然而,這跟私有成員又有什么關系呢?因為私有函數肯定不是虛函數,所以在 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 出現的理由之一就是解決私有化問題,但是為什么要用以及怎么用就需要去分析和思考了。
以上就是本文的全部內容,希望對大家的學習有所幫助,也希望大家多多支持武林網。
新聞熱點
疑難解答