Class field declarations for JavaScript(JavaScript 類的字段聲明)目前已經(jīng)進入了 stage-3,其中包含一項 OOP 開發(fā)者都很關注的內(nèi)容:Private fields。JavaScript 一直沒有私有成員并不是沒有原因,所以這一提議給 JavaScript 帶來了新的挑戰(zhàn)。但同時,JavaScript 在 ES2015 發(fā)布的時候已經(jīng)在考慮私有化的問題了,所以要實現(xiàn)私有成員也并非毫無基礎。
首先挖個坑 —— 這是一段 JS 代碼,BusinessView
?中要干兩件事情,即對表單和地圖進行布局。
代表將?
_
?前綴約定為私有
class?BaseView?{ ????layout()?{????????console.log("BaseView?Layout"); ????} }class?BusinessView?extends?BaseView??{ ????layout()?{????????super.layout();????????this._layoutForm();????????this._layoutMap(); ????} ????_layoutForm()?{????????//?.... ????} ????_layoutMap()?{????????//?.... ????} }
然后,由于業(yè)務的發(fā)展,發(fā)現(xiàn)有很多視圖都存在地圖布局。這里選用繼承的方式來實現(xiàn),所以從?BusinessView
?中把地圖相關的內(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()
?來進行各層次應該負責的布局任務。但理想和現(xiàn)實總是有差距的,在 JavaScript 中運行就會發(fā)現(xiàn)?BusinessView._layoutMap()
?被執(zhí)行了兩次,而?MapView._layoutMap()
?未執(zhí)行。為什么?
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
,所以壓根都沒去搜索原型鏈。對的,這是基于原型關系的 OOP 的局限。如果我們看看 C# 的處理過程,就會發(fā)現(xiàn)有所不同
調(diào)用?BusinessView.layout()
找到?base.layout()
,開始調(diào)用?MapView.layout()
MapView.layout()
?中調(diào)用?this._layoutMap()
如果是,往子類找到最后一個重載(override)函數(shù),調(diào)用
如果不是,直接調(diào)用
在?MapView
?中找到?_layoutMap()
檢查是否虛函數(shù)
發(fā)現(xiàn)區(qū)別了嗎?關鍵是在于判斷“虛函數(shù)”。
然而,這跟私有成員又有什么關系呢?因為私有函數(shù)肯定不是虛函數(shù),所以在 C# 中,如果將?_layoutMap
?定義為私有,那?MapView.layout()
?調(diào)用的就一定是?MapView._layoutMap()
。
虛函數(shù)的概念有點小復雜。不過可以簡單理解為,如果一個成員方法被聲明為虛函數(shù),在調(diào)用的時候就會延著其虛函數(shù)鏈找到最后的重載來進行調(diào)用。
JavaScript 中雖然約定?_
?前綴的是私有,那也只是君子之約,它實質(zhì)上仍然不是私有。君子之約對人有效,計算機又不知道你有這個約定……。但是,如果 JavaScript 真的實現(xiàn)了私有成員,那么計算機就知道了,_layoutMap()
?是個私有方法,應該調(diào)用本類中的定義,而不是去尋找子類中的定義。
JavaScript 當下沒有私有成員,但是我們又需要切時有效地解決私有成員問題,怎么辦?當然有辦法,用?Symbol
?和閉包來解決。
注意,這里的閉包不是指導在函數(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"); ????} }
改革過后的代碼就可以按預期輸出了:
BaseView?Layout MapView?layout?map BusinessView?layout?map
筆者在多年開發(fā)過程中養(yǎng)成了分析和解決問題的一系列思維習慣,所以常常可以迅速的透過現(xiàn)象看到需要解決的實質(zhì)性問題,并基于現(xiàn)有條件來解決它。確實,Sym
bol
?出現(xiàn)的理由之一就是解決私有化問題,但是為什么要用以及怎么用就需要去分析和思考了。bol
?出現(xiàn)的理由之一就是解決私有化問題,但是為什么要用以及怎么用就需要去分析和思考了。
另外有需要云服務器可以了解下創(chuàng)新互聯(lián)scvps.cn,海內(nèi)外云服務器15元起步,三天無理由+7*72小時售后在線,公司持有idc許可證,提供“云服務器、裸金屬服務器、高防服務器、香港服務器、美國服務器、虛擬主機、免備案服務器”等云主機租用服務以及企業(yè)上云的綜合解決方案,具有“安全穩(wěn)定、簡單易用、服務可用性高、性價比高”等特點與優(yōu)勢,專為企業(yè)上云打造定制,能夠滿足用戶豐富、多元化的應用場景需求。
新聞名稱:JavaScript私有成員-創(chuàng)新互聯(lián)
URL分享:http://chinadenli.net/article22/pppcc.html
成都網(wǎng)站建設公司_創(chuàng)新互聯(lián),為您提供網(wǎng)站制作、動態(tài)網(wǎng)站、定制網(wǎng)站、軟件開發(fā)、電子商務、定制開發(fā)
聲明:本網(wǎng)站發(fā)布的內(nèi)容(圖片、視頻和文字)以用戶投稿、用戶轉載內(nèi)容為主,如果涉及侵權請盡快告知,我們將會在第一時間刪除。文章觀點不代表本網(wǎng)站立場,如需處理請聯(lián)系客服。電話:028-86922220;郵箱:631063699@qq.com。內(nèi)容未經(jīng)允許不得轉載,或轉載時需注明來源: 創(chuàng)新互聯(lián)