假設你在你家客廳裏玩遊戲,口渴了,須要到廚房開一壺水,等水開了的時候,爲了防止水熬幹,你須要及時把火爐關掉。爲了及時瞭解到水是否燒開,你有三種策略能夠選擇:編程
1. 守在廚房內,等水燒開設計模式
這種策略顯然是很愚蠢的,採起這種策略,在燒水的過程當中你將不能作任何事情,效率極低。數組
2. 呆在客廳玩遊戲,每隔一兩分鐘跑到廚房看一次瀏覽器
這種策略,在計算機科學中稱爲輪詢,即每隔必定的時間,監測一次。在這裏,也是很不明智的,在玩遊戲時須要不斷的分心。函數
3. 在水壺上安裝一個報警器,當水開了的時候,發出警報優化
這種策略是最好的,既不耽誤本身玩遊戲,又能在水開了的時候使本身及時得到通知。這種策略在計算機中經過事件機制來實現。編碼
經過上面的實例,咱們能夠抽象出一個事件機制有三個組成部分:spa
1.事件源:即事件的發送者,在上例中爲水壺;翻譯
2.事件:事件源發出的一種信息或狀態,好比上例的警報聲,它表明着水開了;設計
3.事件偵聽者:對事件做出反應的對象,好比上例中的你。在設計事件機制時通常把偵聽者設計爲一個函數,當事件發送時,調用此函數。好比上例中能夠把倒水設計爲偵聽者。
可使用面向對象設計中的組合模式,把事件偵聽者當作事件源內部的一個對象,當事件發生時,調用偵聽者便可:
1 事件源:水壺{ 2 事件偵聽者:你關火;//事件源持有事件偵聽者 3 4 發送(事件:「水開了」){ 5 你關火(); 6 } 7 }
若是你和你女友都在客廳玩遊戲,水開的時候應該誰去關火呢?假設精明(懶惰)的你,聽到水開的警報聲,立刻僞裝上廁所,你女友只能無奈地去關火。這種狀況下,水壺發出的警報聲致使了兩個反應:1.你上廁所,2.你女友去關火。此時咱們要如何實現呢?咱們依然能夠採用上面的實現方案,再在事件源中添加一個事件偵聽者:
1 事件源:水壺{ 2 事件偵聽者:你上廁所; 3 事件偵聽者:你女友關火; 4 5 發送(事件:「水開了」){ 6 你上廁所(); 7 你女友關火(); 8 } 9 10 }
但這種設計有一個重大缺陷:事件源和事件偵聽者過分耦合。全部偵聽者都是硬編碼入事件源中,在程序執行過程當中沒法更改,靈活性極差。好比,有一天你女友外出了,只能你去關火,那麼上面的事件源就須要從新修改。咱們能夠採用下面的方法使事件源和事件偵聽者解耦:
1.事件源中定義一個列表,好比數組,用來存儲全部偵聽者;
2.爲列表留一個增刪數據的接口,用來隨時添加和刪除偵聽者;
3.當發送事件時,遍歷並執行列表中的偵聽者
實現以下:
1 事件源:水壺{ 2 3 事件偵聽者:偵聽者列表[]; 4 5 添加事件偵聽者(偵聽者){ 6 偵聽者列表加入偵聽者 7 } 8 刪除事件偵聽者(偵聽者){ 9 偵聽者列表移除偵聽者 10 } 11 12 發送(事件){ 13 //遍歷並執行列表中的偵聽者 14 for(偵聽者 in 偵聽者列表){ 15 執行偵聽者 16 } 17 } 18 19 }
這種實現方案即爲觀察者設計模式,可讓偵聽者預訂事件。
假設你家的水壺有點智能,當水溫達到90度的時候,會發出一個「水快開了」的警報,爲你提早逃到廁所偷懶留出了充足的時間,這種狀況下的事件和偵聽者的對應關係以下:
咱們能夠在添加和刪除偵聽者的時候,把事件類型和偵聽者綁定成一個數組(或對象),再加入偵聽者列表。在發送事件時,在列表中查找和當前事件綁定的偵聽器執行:
事件源:水壺{ 事件偵聽者:偵聽者列表[]; 添加事件偵聽者(事件類型,偵聽者){ 帶類型偵聽者=[事件類型,偵聽者];//經過數組把事件類型和偵聽者綁定 偵聽者列表加入帶類型偵聽者; } 刪除事件偵聽者(事件類型,偵聽者){ 經過事件類型和偵聽者查找列表中對應的偵聽器刪除; } 發送(事件類型){ //遍歷並執行列表中的偵聽者 for(帶類型偵聽者 in 偵聽者列表){ if(帶類型偵聽者[0]==事件類型){ 帶類型偵聽者[1]()//執行對應的偵聽器 } } } }
把上面的文字描述翻譯成僞碼以下:
1 //水壺類 2 Kettle{ 3 4 array:Listeners[]; 5 6 addEventListener(eventType,listener){ 7 typeListener=[eventType,listener];//經過數組把事件類型和偵聽者綁定 8 Listeners.push(typeListener); 9 } 10 11 removeEventListener(eventType,listener){ 12 Listeners.delete([eventType,listener]); 13 } 14 15 dispatch(eventType){ 16 //遍歷並執行列表中的偵聽者 17 for(typeListener in Listeners){ 18 if(typeListener[0]==eventType){ 19 typeListener[1]()//執行對應的偵聽器 20 } 21 } 22 } 23 24 } 25 26 goWc(){ 27 //你上廁所 28 } 29 30 turnOffFire(){ 31 //女友關火 32 } 33 34 kettle=new Kettle(); 35 //水壺註冊水快開了事件 36 kettle.addEventListener("水快開了",goWC); 37 kettle.addEventListener("水開了",turnOffFire); 38 kettle.dispatch("水快開了");
優化:遵循"針對接口編程"的設計原則,應該爲水壺、事件、偵聽器設計一個基類,其餘具體的類繼承這些基類;
當事件發生在顯示對象上(好比瀏覽器)的時候,會遇到一個頗有趣的問題:頁面的那一部分會擁有某個特定的事件?好比當你點擊頁面上的一棟小房子的時候,根據視角的遠近,你點擊的對象會發生變化。從最遠處來看你點擊的是頁面,鏡頭拉近你點擊的是小房子,再拉近你點擊的是房子上的一面牆,再拉近你點擊的是牆上的一塊磚。也就是說,你點擊一次頁面也許會有不少顯示對象發生了點擊事件,若是你在每個顯示對象上都綁定了點擊處理程序,那麼這些程序都會執行。這裏會遇到一個問題:這些程序按什麼順序執行。這取決於顯示對象接受到點擊事件的順序,通常有兩種模式:事件冒泡和事件捕獲。這種事件在顯示對象上按順序發生的過程稱爲事件流。
1. 事件冒泡
事件冒泡,即事件開始時由最具體的元素(好比上例的磚塊)接受,而後逐級向上傳播到較爲不具體的節點(文檔);
2. 事件捕獲
事件捕獲的思想是不太具體的元素(文檔)更早的接受事件,而最具體的元素最後接受到事件(磚塊)。事件捕獲的用意在於事件到達預訂目標之間捕獲它。
在JavaScript中爲DOM中的元素添加事件處理程序時,有三個參數,其中第三個參數是一個布爾值,當爲true時,表示在捕獲階段調用事件處理程序,爲false時,表示在冒泡階段調用事件處理程序,舉例以下:
1 <body> 2 <div id="outer"> 3 <div id="inner" > 4 </div> 5 </div> 6 </body> 7 8 //例一 9 var btn1=document.getElementById("outer"); 10 btn1.addEventListener("click",function(){ 11 alert('outer') 12 },false); 13 14 var btn2=document.getElementById("inner"); 15 btn2.addEventListener("click",function(){ 16 alert('inner') 17 },false); 18 19 //例二 20 var btn1=document.getElementById("outer"); 21 btn1.addEventListener("click",function(){ 22 alert('outer') 23 },false); 24 25 var btn2=document.getElementById("inner"); 26 btn2.addEventListener("click",function(){ 27 alert('inner') 28 },false);
上面例一的事件處理程序都發生在冒泡階段,因此會先輸出inner,再輸出outer。例二中id爲outer元素上的事件處理程序發生在捕獲階段,因此會先輸出outer,再輸出inner。
注意:事件流發生在父元素和子元素之間,而不是兩個同級的元素。