詳解javascript中的this對象
前言
javascript是一門基于對象的動态語言,也就是說,所有東西都是對象,一個很典型的例子就是函數也被視為普通的對象。javascript可以通過一定的設計模式來實作面向對象的程式設計,其中this “指針”就是實作面向對象的一個很重要的特性。但是this也是javascript中一個非常容易了解錯,進而用錯的特性。特别是對于接觸靜态語言比較久了的同志來說更是如此。
示例說明
我們先來看一個最簡單的示例:
<script type="text/javascript">
var name = "kevin yang";
function sayhi(){
alert("你好,我的名字叫" + name);
}
sayhi();
</script>
這段代碼很簡單,我們定義了一個全局字元串對象name和函數對象sayhi。運作會彈出一個打招呼的對話框,“你好,我的名字叫kevin yang”。
我們把這段代碼稍微改一改:
alert("你好,我的名字叫" + this.name);
這段代碼和上段代碼的差別就在于sayhi函數在使用name的時候加上了this.字首。運作結果和上面一摸一樣。這說明this.name引用的也還是全局的name對象。
開頭我們不是說了,函數也是普通的對象,可以将其當作一個普通變量使用。我們再把上面的代碼改一改:
var person = {};
person.sayhello = sayhi;
person.sayhello();
這一次,我們又建立了一個全局對象person,并将sayhi函數對象賦給person對象的sayhello屬性。運作結果如下:
這一次打招呼的内容就有點無厘頭了,我們發現this.name已經變成undefined了。這說明,在sayhello函數内部執行時已經找不着this.name對象了。如果我們重新定義person對象,在其上面加上一個name屬性又會怎麼樣呢?
var person = {name:"marry"};
運作代碼發現打招呼的“人”變了:
是不是看出點道道了呢?
判别this指針的指導性原則
在javascript裡面,this指針代表的是執行目前代碼的對象的所有者。
在上面的示例中我們可以看到,第一次,我們定義了一個全局函數對象sayhi并執行了這個函數,函數内部使用了this關鍵字,那麼執行this這行代碼的對象是sayhi(一切皆對象的展現),sayhi是被定義在全局作用域中。其實在javascript中所謂的全局對象,無非是定義在window這個根對象下的一個屬性而已。是以,sayhi的所有者是window對象。也就是說,在全局作用域下,你可以通過直接使用name去引用這個對象,你也可以通過window.name去引用同一個對象。因而this.name就可以翻譯為window.name了。
再來看第二個this的示例。我們定義了一個person的對象,并定義了它的sayhello屬性,使其指向sayhi全局對象。那麼這個時候,當我們運作person.sayhello的時候,this所在的代碼所屬對象就是sayhello了(其實準确來說,sayhi和sayhello是隻不過類似兩個指針,指向的對象實際上是同一個),而sayhello對象的所有者就是person了。第一次,person裡面沒有name屬性,是以彈出的對話框就是this.name引用的就是undefined對象(javascript中所有隻聲明而沒有定義的變量全都指向undefined對象);而第二次我們在定義person的時候加了name屬性了,那麼this.name指向的自然就是我們定義的字元串了。
了解了上面所說的之後,我們将上面最後一段示例改造成面向對象式的代碼。
function person(name){
this.name = name;
person.prototype.sayhello = sayhi;
var marry = new person("marry");
marry.sayhello();
var kevin = new person("kevin");
kevin.sayhello();
在上面這段代碼中,我們定義了一個person的“類”(實際上還是一個對象),然後在這個類的原型(類原型相當于c++中的靜态成員變量的概念)中定義了sayhello屬性,使其指向全局的sayhi對象。運作代碼我們可以看到,marry和kevin都成功的向我們打了聲“招呼”。
在這段代碼中有兩點需要思考的,一個是new我們很熟悉,但是在這裡new到底做了什麼操作呢?另外一個是,這裡執行sayhello的時候,this指針為什麼能夠正确的指向marry和kevin對象呢?
我們來把上面定義“類”和執行個體化類對象的操作重新“翻譯”一下:
var this;
return this;
var marry = person("marry");
var kevin = person("kevin");
當然這段代碼并不能正确執行,但是它可以幫助你更好的了解這個過程。
當我們使用new關鍵字執行個體化一個“類”對象的時候,javascript引擎會在這個對象内部定義一個新的對象并将其存入this指針。所有此對象内部用到this的代碼實際上都是指向這個新的對象。如this.name = name,實際上是将參數中的name對象指派給了這個新建立的對象。函數對象執行完之後javascript引擎會将此對象傳回給你,于是就有marry變量得到的對象的name為“marry”,而kevin變量得到的對象的name屬性确實“kevin”。
顯式操縱this指針
在上面的面向對象式程式設計執行個體中,我們看到,在使用new操作符的情況下,看起來this的指向和我們前一節中講到的指導原則并不相符。 this指針并沒有指向marry或者kevin的所有者,而是指向marry和kevin變量本身。
實際上,如果你了解什麼是指針的話,那麼你就會知道,既然是指針,那麼當然可以改變其指向的對象。隻不過javascript引擎不允許我們自己寫代碼來做這樣的事情,也就是說,在javascript中,你不可以直接寫this = someobj這樣的代碼。javascript引擎通過以下兩種方式允許我們顯式指定this指針指代的對象:
1. 通過new操作符,javascript引擎會将this指針傳回給被指派的變量a(對應上面的例子就是marry和kevin變量),這個時候a和 this指針引用的就是同一個對象了,即a == this。過程參見上面的僞代碼。
2. 通過function.apply或者function.call的原型方法,我們可以将this指針指代的對象以參數的形式傳入,這個時候,函數内部使用的this指針就是傳入的參數。
注意,對于這種顯式指定this指針的情況,上一節提到的指導原則不再适用。
容易誤用的情況
了解了this指針後,我們再來看看一些很容易誤用this指針的情況。
示例1——内聯式綁定dom元素的事件處理函數
alert("目前點選的元素是" + this.tagname);
}
<input id="btntest" type="button" value="點選我" onclick="sayhi()">
在此例代碼中,我們綁定了button的點選事件,期望在彈出的對話框中列印出點選元素的标簽名。但運作結果卻是:
也就是this指針并不是指向input元素。這是因為當使用内聯式綁定dom元素的事件處理函數時,實際上相當于執行了以下代碼:
<script type="text/javascript">
document.getelementbyid("btntest").onclick = function(){
sayhi();
在這種情況下sayhi函數對象的所有權并沒有發生轉移,還是屬于window所有。用上面的指導原則一套我們就很好了解為什麼this.tagname是undefined了。
那麼如果我們要引用元素本身怎麼辦呢?
我們知道,onclick函數是屬于btntest元素的,那麼在此函數内部,this指針正是指向此dom對象,于是我們隻需要把this作為參數傳入sayhi即可。
function sayhi(el){
alert("目前點選的元素是" + el.tagname);
<input id="btntest" type="button" value="點選我" onclick="sayhi(this)">
等價代碼如下:
<script type="text/javascript">
sayhi(this);
示例2——臨時變量導緻的this指針丢失
var utility = {
decode:function(str){
return unescape(str);
},
getcookie:function(key){
// ... 省略提取cookie字元串的代碼
var value = "i%27m%20a%20cookie";
return this.decode(value);
}
};
alert(utility.getcookie("identity"))
我們在寫稍微有點規模的js庫的時候,一般都會自己封裝一個utility的類,然後将一些常用的函數作為utility類的屬性,如用戶端經常會用到的getcookie函數和解碼函數。如果每個函數都是彼此獨立的,那麼還好辦,問題是,函數之間有時候會互相引用。例如上面的getcookie函數,會對從document.cookie中提取到的字元串進行decode之後再傳回。如果我們通過utility.getcookie去調用的話,那麼沒有問題,我們知道,getcookie内部的this指針指向的還是utility對象,而utility對象時包含decode屬性的。代碼可以成功執行。
但是有個人不小心這樣使用utility對象呢?
function showuseridentity(){
// 儲存getcookie函數到一個局部變量,因為下面會經常用到
var getcookie = utility.getcookie;
alert(getcookie("identity"));
showuseridentity();
這個時候運作代碼會抛出異常“this.decode is not a function”。運用上面我們講到的指導原則,很好了解,因為此時utility.getcookie對象被賦給了臨時變量getcookie,而臨時變量是屬于window對象的——隻不過外界不能直接引用,隻對javascript引擎可見——于是在getcookie函數内部的this指針指向的就是window對象了,而window對象沒有定義一個decode的函數對象,是以就會抛出這樣的異常來。
這個問題是由于引入了臨時變量導緻的this指針的轉移。解決此問題的辦法有幾個:
不引入臨時變量,每次使用均使用utility.getcookie進行調用
getcookie函數内部使用utility.decode顯式引用decode對象而不通過this指針隐式引用(如果utility是一個執行個體化的對象,也即是通過new生成的,那麼此法不可用)
使用funtion.apply或者function.call函數指定this指針
前面兩種都比較好了解,第三種需要提一下。正是因為this指針的指向很容易被轉移丢失,是以javascript提供了兩個類似的函數apply和call來允許函數在調用時重新顯式的指定this指針。
修正代碼如下:
alert(getcookie.call(utility,"identity"));
alert(getcookie.apply(utility,["identity"]));
call和apply隻有文法上的差異,沒有功能上的差别。
示例3——函數傳參時導緻的this指針丢失
我們先來看一段問題代碼:
var person = {
name:"kevin yang",
sayhi:function(){
alert("你好,我是"+this.name);
settimeout(person.sayhi,5000);
這段代碼期望在訪客進入頁面5秒鐘之後向訪客打聲招呼。settimeout函數接收一個函數作為參數,并在指定的觸發時刻執行這個函數。可是,當我們等了5秒鐘之後,彈出的對話框顯示的this.name卻是undefined。
其實這個問題和上一個示例中的問題是類似的,都是因為臨時變量而導緻的問題。當我們執行函數的時候,如果函數帶有參數,那麼這個時候javascript引擎會建立一個臨時變量,并将傳入的參數複制(注意,javascript裡面都是值傳遞的,沒有引用傳遞的概念)給此臨時變量。也就是說,整個過程就跟上面我們定義了一個getcookie的臨時變量,再将utility.getcookie指派給這個臨時變量一樣。隻不過在這個示例中,容易忽視臨時變量導緻的bug。
函數對象傳參
對于函數作為參數傳遞導緻的this指針丢失的問題,目前很多架構都已經有方法解決了。
prototype的解決方案——傳參之前使用bind方法将函數封裝起來,并傳回封裝後的對象
var boundfunc = person.sayhi.bind(person,person.sayhi);
settimeout(boundfunc,5000);
bind方法的實作其實是用到了javascript又一個進階特性——閉包。我們來看一下源代碼:
function bind(){
if (arguments.length < 2 && arguments[0] === undefined)
var __method = this, args = $a(arguments), object = args.shift();
return function(){
return __method.apply(object, args.concat($a(arguments)));
}
首先将this指針存入函數内部臨時變量,然後在傳回的函數對象中引用此臨時變量進而形成閉包。
微軟的ajax庫提供的方案——建構委托對象
var boundfunc = function.createdelegate(person,person.sayhi);
其實本質上和prototype的方式是一樣的。
著名的extjs庫的解決方案采用的手法和微軟是一樣的。