本篇內(nèi)容介紹了“如何編寫.NET事件監(jiān)聽機制的局限與擴展”的有關(guān)知識，在實際案例的操作過程中，不少人都會遇到這樣的困境，接下來就讓小編帶領(lǐng)大家學(xué)習(xí)一下如何處理這些情況吧！希望大家仔細閱讀，能夠?qū)W有所成！

為榮成等地區(qū)用戶提供了全套網(wǎng)頁設(shè)計制作服務(wù)，及榮成網(wǎng)站建設(shè)行業(yè)解決方案。主營業(yè)務(wù)為做網(wǎng)站、網(wǎng)站設(shè)計、榮成網(wǎng)站設(shè)計，以傳統(tǒng)方式定制建設(shè)網(wǎng)站，并提供域名空間備案等一條龍服務(wù)，秉承以專業(yè)、用心的態(tài)度為用戶提供真誠的服務(wù)。我們深信只要達到每一位用戶的要求，就會得到認可，從而選擇與我們長期合作。這樣，我們也可以走得更遠！

具體分析如下：

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

復(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)聽機制對監(jiān)聽者的調(diào)用順序沒有明確的保證，但有時我們卻要求保證不同組件之間的處理順序。比如，在我們的軟件中使用類似解釋器模式的方式來實現(xiàn)用戶交互操作，一個稱作交互源的組件負責(zé)將UI控件上的事件分派給一組稱為交互器的組件，這些組件依照事先確定的優(yōu)先級依次獲得事件處理的機會，只有當(dāng)具有高優(yōu)先級的交互器沒有處理事件時，低優(yōu)先級的組件才能執(zhí)行進一步的處理。這樣，我們就能在不同業(yè)務(wù)功能的實現(xiàn)中通過以不同的順序組織交互器來重用它們。比如，重用一些基本的視圖縮放、平移、菜單處理等功能。
 
在上述場景下，如何保證交互器間事件處理的順序就變得很重要了。當(dāng)然如果你看一下MulticastDelegate的源代碼的話，可以知道在當(dāng)前的實現(xiàn)中其實各個監(jiān)聽者還是有一定的調(diào)用順序的。但一來這屬于實現(xiàn)細節(jié)，在將來完全可能改變；二來如果不同的監(jiān)聽器位于不同的模塊中時，要依賴于這一實現(xiàn)而保證它們之間的調(diào)用順序也是很困難的。
 
在這里我們借鑒了Java中以接口進行事件處理的方式，并在添加監(jiān)聽器的同時接收一個表示優(yōu)先級的參數(shù)，這樣就可以明確的維護各個監(jiān)聽器的順序了，如下面的代碼所示。我們在交互器（IInteractor）接口中為每一個UI事件定義了相應(yīng)的方法，并且讓InteractSource負責(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）機制背后的實現(xiàn)，通過其源代碼可以看到，它在內(nèi)部使用數(shù)組保存了對各個監(jiān)聽器的引用。這就會造成一個問題——當(dāng)對一個事件的監(jiān)聽器數(shù)目很多時，添加和移除監(jiān)聽器的效率將會變得非常低。以移除為例，對于有N個監(jiān)聽器的事件來說，平均要進行N/2次比較才能確定監(jiān)聽器的位置，而且還要有額外的數(shù)組整理操作。為了解決這一情況，我們先是嘗試自行定義事件的添加、移除邏輯，并在內(nèi)部嘗試使用字典、哈希表等多種方式進行存儲，但事實證明，雖然二者在時間復(fù)雜度上有優(yōu)勢，不過其實際效率還是達不到要求。
 
好狀態(tài)下是要有一種能在常數(shù)時間內(nèi)添加和移除監(jiān)聽器的數(shù)據(jù)結(jié)構(gòu)，也許你也想到了——雙向鏈表。
 
也許你又想到了——在雙向鏈表中添加和刪除是常數(shù)時間，但查找卻仍然是O(n)的復(fù)雜度。
 
使用接口形式的設(shè)計方式再次展現(xiàn)了其靈活性，我們可以將事件發(fā)布者的設(shè)計為如下形式（示意代碼）：

復(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é)點保存到一個令牌（Token）中返回。監(jiān)聽者需要保存這個令牌，并使用它來解除監(jiān)聽。當(dāng)然，監(jiān)聽者完全可以忽略令牌是個什么東西，就像地鐵票從來就是只是一張票而已，我們不曾關(guān)心它包含著什么信息。不過對于發(fā)布者來說卻可以將一些定位信息保存在其中，從而在解除監(jiān)聽時充分利用，在上面的代碼中我就保存了鏈表節(jié)點的引用，從而達到監(jiān)聽者的添加、定位、移除都在常數(shù)時間內(nèi)完成。

“如何編寫.NET事件監(jiān)聽機制的局限與擴展”的內(nèi)容就介紹到這里了，感謝大家的閱讀。如果想了解更多行業(yè)相關(guān)的知識可以關(guān)注創(chuàng)新互聯(lián)網(wǎng)站，小編將為大家輸出更多高質(zhì)量的實用文章！

分享文章：如何編寫.NET事件監(jiān)聽機制的局限與擴展-創(chuàng)新互聯(lián)
路徑分享：http://www.aaarwkj.com/article44/pjsee.html

成都網(wǎng)站建設(shè)公司_創(chuàng)新互聯(lián)，為您提供面包屑導(dǎo)航、網(wǎng)頁設(shè)計公司、網(wǎng)站建設(shè)、響應(yīng)式網(wǎng)站、定制開發(fā)、網(wǎng)站收錄

廣告

聲明：本網(wǎng)站發(fā)布的內(nèi)容（圖片、視頻和文字）以用戶投稿、用戶轉(zhuǎn)載內(nèi)容為主，如果涉及侵權(quán)請盡快告知，我們將會在第一時間刪除。文章觀點不代表本網(wǎng)站立場，如需處理請聯(lián)系客服。電話：028-86922220；郵箱：631063699@qq.com。內(nèi)容未經(jīng)允許不得轉(zhuǎn)載，或轉(zhuǎn)載時需注明來源： 創(chuàng)新互聯(lián)