主頁 > 知識庫 > .NET事件監(jiān)聽機(jī)制的局限與擴(kuò)展分析

.NET事件監(jiān)聽機(jī)制的局限與擴(kuò)展分析

熱門標(biāo)簽:河南語音外呼系統(tǒng)公司 威海電銷 400免費(fèi)電話怎么辦理 t3出行地圖標(biāo)注怎么做 河北網(wǎng)絡(luò)回?fù)芡夂粝到y(tǒng) 外呼電銷機(jī)器人軟件 400電話辦理最優(yōu)質(zhì) 寧夏機(jī)器人電銷 關(guān)于宗地圖標(biāo)注技術(shù)規(guī)范

本文實(shí)例分析了.NET事件監(jiān)聽機(jī)制的局限與擴(kuò)展。分享給大家供大家參考。具體分析如下:

.NET中把“事件”看作一個基本的編程概念,并提供了非常優(yōu)美的語法支持,對比如下C#和Java代碼可以看出兩種語言設(shè)計(jì)思想之間的差異。

復(fù)制代碼 代碼如下:
// C#
someButton.Click += OnSomeButtonClick;

復(fù)制代碼 代碼如下:
// Java
someButton.addActionListener(
    new ActionListener(){
        public void actionPerformed(){
            ...
        }
});

在我們的軟件中就大量使用事件來對監(jiān)聽者與發(fā)布者解耦,但也遇到了一些局限,在這里跟大家分享一二。一是無法保證監(jiān)聽者的調(diào)用順序;二是當(dāng)監(jiān)聽者很多時的監(jiān)聽、解除監(jiān)聽的效率問題。
 
事件監(jiān)聽者的調(diào)用順序

.NET的事件監(jiān)聽機(jī)制對監(jiān)聽者的調(diào)用順序沒有明確的保證,但有時我們卻要求保證不同組件之間的處理順序。比如,在我們的軟件中使用類似解釋器模式的方式來實(shí)現(xiàn)用戶交互操作,一個稱作交互源的組件負(fù)責(zé)將UI控件上的事件分派給一組稱為交互器的組件,這些組件依照事先確定的優(yōu)先級依次獲得事件處理的機(jī)會,只有當(dāng)具有高優(yōu)先級的交互器沒有處理事件時,低優(yōu)先級的組件才能執(zhí)行進(jìn)一步的處理。這樣,我們就能在不同業(yè)務(wù)功能的實(shí)現(xiàn)中通過以不同的順序組織交互器來重用它們。比如,重用一些基本的視圖縮放、平移、菜單處理等功能。
 
在上述場景下,如何保證交互器間事件處理的順序就變得很重要了。當(dāng)然如果你看一下MulticastDelegate的源代碼的話,可以知道在當(dāng)前的實(shí)現(xiàn)中其實(shí)各個監(jiān)聽者還是有一定的調(diào)用順序的。但一來這屬于實(shí)現(xiàn)細(xì)節(jié),在將來完全可能改變;二來如果不同的監(jiān)聽器位于不同的模塊中時,要依賴于這一實(shí)現(xiàn)而保證它們之間的調(diào)用順序也是很困難的。
 
在這里我們借鑒了Java中以接口進(jìn)行事件處理的方式,并在添加監(jiān)聽器的同時接收一個表示優(yōu)先級的參數(shù),這樣就可以明確的維護(hù)各個監(jiān)聽器的順序了,如下面的代碼所示。我們在交互器(IInteractor)接口中為每一個UI事件定義了相應(yīng)的方法,并且讓InteractSource負(fù)責(zé)將控件上的事件轉(zhuǎn)化為對接口中相應(yīng)方法的調(diào)用。

復(fù)制代碼 代碼如下:
public class InteractSource
{
    public void AddInteractor(int priority, IInteractor interactor)
    {
    }
}
 
public interface IInteractor
{
    public void OnMouseDown(MouseEventArgs e)
    {
    }
   
    ... ...
}

監(jiān)聽器添加與移除的效率

MulticastDelegate是我們平常使用的事件(event)機(jī)制背后的實(shí)現(xiàn),通過其源代碼可以看到,它在內(nèi)部使用數(shù)組保存了對各個監(jiān)聽器的引用。這就會造成一個問題——當(dāng)對一個事件的監(jiān)聽器數(shù)目很多時,添加和移除監(jiān)聽器的效率將會變得非常低。以移除為例,對于有N個監(jiān)聽器的事件來說,平均要進(jìn)行N/2次比較才能確定監(jiān)聽器的位置,而且還要有額外的數(shù)組整理操作。為了解決這一情況,我們先是嘗試自行定義事件的添加、移除邏輯,并在內(nèi)部嘗試使用字典、哈希表等多種方式進(jìn)行存儲,但事實(shí)證明,雖然二者在時間復(fù)雜度上有優(yōu)勢,不過其實(shí)際效率還是達(dá)不到要求。
 
最好狀態(tài)下是要有一種能在常數(shù)時間內(nèi)添加和移除監(jiān)聽器的數(shù)據(jù)結(jié)構(gòu),也許你也想到了——雙向鏈表。
 
也許你又想到了——在雙向鏈表中添加和刪除是常數(shù)時間,但查找卻仍然是O(n)的復(fù)雜度。
 
使用接口形式的設(shè)計(jì)方式再次展現(xiàn)了其靈活性,我們可以將事件發(fā)布者的設(shè)計(jì)為如下形式(示意代碼):

復(fù)制代碼 代碼如下:
public class EventSource
{
    private LinkedList list = new LinkedList();
 
    public Tocken AddListener(IEventListener listener)
    {
        LinkedListNode n = new LinkedListNode(listener);
        list.AddLast(n);
        return new Tocken(node);
    }
 
    public void RemoveListener(Tocken tocken)
    {
        list.Remoe(tocken.node);
    }
 
    public class Tocken
    {
        internal LinkedListNode node;
    }
}

在此類中使用雙向鏈表存儲已經(jīng)添加的監(jiān)聽器,而在AddListener方法每次調(diào)用時都將所添加的鏈表節(jié)點(diǎn)保存到一個令牌(Token)中返回。監(jiān)聽者需要保存這個令牌,并使用它來解除監(jiān)聽。當(dāng)然,監(jiān)聽者完全可以忽略令牌是個什么東西,就像地鐵票從來就是只是一張票而已,我們不曾關(guān)心它包含著什么信息。不過對于發(fā)布者來說卻可以將一些定位信息保存在其中,從而在解除監(jiān)聽時充分利用,在上面的代碼中我就保存了鏈表節(jié)點(diǎn)的引用,從而達(dá)到監(jiān)聽者的添加、定位、移除都在常數(shù)時間內(nèi)完成。
 
當(dāng)然,還可以在Tocken中保存發(fā)布者的引用,這樣就可以發(fā)現(xiàn)”取消對一個從來沒有監(jiān)聽過的對象的監(jiān)聽“這樣的BUG。或者,還有其它信息。

希望本文所述對大家的C#程序設(shè)計(jì)有所幫助。

您可能感興趣的文章:
  • .NET開發(fā)基礎(chǔ):從簡單的例子理解泛型 分享
  • .net泛型通用函數(shù)的特殊問題的解決方法
  • 使用.NET中的Action及Func泛型委托深入剖析
  • .net使用自定義類屬性實(shí)例
  • asp.net自定義控件中注冊Javascript問題解決方案
  • .net自定義事件示例分享
  • asp.net自定義分頁控件示例
  • 關(guān)于asp.net 自定義分頁控件
  • ASP.Net巧用窗體母版頁實(shí)例
  • .NET基礎(chǔ)之自定義泛型分析

標(biāo)簽:賀州 樂山 固原 咸寧 池州 廣元 淮北 吉林

巨人網(wǎng)絡(luò)通訊聲明:本文標(biāo)題《.NET事件監(jiān)聽機(jī)制的局限與擴(kuò)展分析》,本文關(guān)鍵詞  .NET,事件,監(jiān)聽,機(jī)制,的,;如發(fā)現(xiàn)本文內(nèi)容存在版權(quán)問題,煩請?zhí)峁┫嚓P(guān)信息告之我們,我們將及時溝通與處理。本站內(nèi)容系統(tǒng)采集于網(wǎng)絡(luò),涉及言論、版權(quán)與本站無關(guān)。
  • 相關(guān)文章
  • 下面列出與本文章《.NET事件監(jiān)聽機(jī)制的局限與擴(kuò)展分析》相關(guān)的同類信息!
  • 本頁收集關(guān)于.NET事件監(jiān)聽機(jī)制的局限與擴(kuò)展分析的相關(guān)信息資訊供網(wǎng)民參考!
  • 推薦文章