這篇文章主要介紹了詳解JavaScript中的客戶端消息框架設計原理,包括客戶端和服務器端的通信等方面的內容,需要的朋友可以參考下
哇——是個危險的題目,對嗎?我們對于什么是本質的理解當然會隨著我們對要解決問題的理解而變化。因此我不會說謊——一年前我所理解的本質很不幸并不完整,因為我確信我將要寫的已經快伴隨我有6個月之久。所以,這篇文章是我在發現JavaScript中成功的運用客戶端消息模式的一些關鍵要點時的一個掠影。
1.) 理解中介者與觀察者的區別
大多數人在描述任何事件/消息機制的時候喜歡套用“發布者/訂閱者”(pub/sub)——但我認為這個術語不能很好的與抽象建立聯系。當然,從根本上說,一些東西訂閱了另一些東西發布的事件。但是發布者與訂閱者在何等層次上封裝在一起有可能使一個好的模式變得暗淡無光。那么,區別在什么地方呢?
觀察者
觀察者模式包括了被一個或多個觀察者所觀察的某個對象。典型的,該對象記錄下所有觀察者的痕跡,通常是用一個list來存儲觀察者注冊的回調方法,這些是觀察者為了接收通知而訂閱的。 注意: (哦,雙關語,我有多愛他們啊)(譯者注:Observe 觀察、注意)
?
1 2 3 4 5 6 7 var observer = { listen : function() { console.log("Yay for more cliché examples..."); } }; var elem = document.getElementById("cliche"); elem.addEventListener("click", observer.listen);一些需要注意的事情是:
我們必須獲得對此對象的直接引用
此對象必須保持一些內部的狀態,保存觀察者的回調痕跡
有時偵聽者不會利用由此對象返回的任何參數,理論上來說,有可能有 0-n*個參數 (更多是取決于以后會變得多有趣)
* n事實上不是無限的,但為了討論的目的,它指我們永遠也達不到的極限
中介者
中介者模式在一個對象與一個觀察者之間引入了一個“第三方”——有效的將二者解耦而且將他們之間如何通信封裝起來。一個中介者的API可能像“發布”、“訂閱”、“取消訂閱”一樣簡單,或者某個領域范圍內的實現可能被提供用來隱藏這些方法于某些更有意義的語義之中。大多數我用過的服務器端的實現更傾向于領域范圍而不是更簡單,但是并沒有對一個通用的中介者有任何規則限制!并不罕見,有種想法認為一個通用的中介者是一種信息經紀人。無論何種情形,結果都一樣——特定對象與觀察者之間不再互相直接知曉:
?
1 2 3 4 5 6 7 8 9 10 11新聞熱點
疑難解答