. The limitation and extension of net event monitoring mechanism

. NET "event" as a basic programming concept, and provides a very beautiful syntax support, for example, the next C # and Java code can see the differences between the two language design ideas.

C#somebutton.click + = Onsomebuttonclick; copy code//Javasomebutton.addactionlistener (new ActionListener () {public    void actionperformed () {...} }); Copy code in our software is a lot of use of events to the listener and publisher decoupling, but also encountered some limitations, here to share with you one or two. One is unable to guarantee the listener's sequence of calls, and the second is when the listener is a lot of monitoring, the efficiency of lifting the monitoring. The order in which event listeners are called. NET's event monitoring mechanism does not guarantee the listener's call order, but sometimes we ask for differentComponentsThe processing order between them. For example, using a similar interpreter pattern in our software to implement user interaction, a component called an interaction source is responsible for assigning events on the UI control to a set of components called the interaction, which in turn gets the opportunity for event handling in order of predetermined precedence. A low-priority component can perform further processing only if a high-priority interaction does not handle the event. In this way, we can reuse them by organizing the interaction in different order in the implementation of different business functions. For example, reuse some basic view zoom, pan, menu processing and other functions.   In the above scenario, it is important to ensure that the sequence of event processing between the interactions is made. Of course, if you look at the source code of MulticastDelegate, you can know that in the current implementation of the listener in fact, there is a certain sequence of calls. But one of these is the implementation details that are likely to change in the future; Secondly, if different listeners are in different modules, it is difficult to rely on this implementation to ensure that the order of calls between them is not.   Here we draw on the way in which the interface is handled in Java, and receive a parameter that represents precedence while adding listeners, so that the order of the listeners can be clearly maintained, as shown in the following code. We define the appropriate method for each UI event in the Iinteractor interface, and let Interactsource be responsible for translating the events on the control into calls to the corresponding methods in the docking port.   Copy code public class interactsource{    public void addinteractor (int priority, Iinteractor interactor)      {   }} public interface iinteractor{    public void OnMouseDown ( MouseEventArgs e)     {   }        ...} The efficiency of copy Code listener Additions and Removal multicastdelegate is the implementation behind the event mechanism we normally use, which we can see through its source code, which internally uses an array to hold references to individual listeners. This creates a problem-when the number of listeners to an event is large, the efficiency of adding and removing listeners becomes very low. To remove, for example, for an event with n listeners, an average of N/2 comparisons can be made to determine the location of the listener, as well as additional array grooming operations. To solve this situation, we first try to define the addition, removal logic of the event, and try to store it internally using a dictionary, a hash table, and so on, but it turns out that although they have an advantage in terms of time complexity, their actual efficiency is still not up to the requirement.   The best state is to have a data structure that can add and remove listeners in constant time, perhaps you also think of a doubly linked list.   Maybe you think of it again-adding and removing in a doubly linked list is a constant time, but finding is still the complexity of O (n).   uses the interface form of design to show its flexibility again, we can design the event Publisher as the following form (schematic code):  Copy code public class eventsource{    private LinkedList list = new LinkedList ();     public Tocken AddListener (Ieventlistener listener)     {& nbsp       LinkedListNode n = new LinkedListNode (listener);        list. AddLast (n);        return new Tocken (node);   }     public void Removelisten ER (tocken tocken)     {        list. Remoe (Tocken.node);   }     public class tocken    {        Intern Al LinkedListNode node;   }} The replication code uses a doubly linked list in this class to store the listeners that have been added, and when the AddListener method is called each time the added list node is saved to a token (tokens). Listeners need to save this token and makeUse it to unblock the listener. Of course, the listener can totally ignore what the token is, like the subway ticket is just a ticket, and we don't care what information it contains. However, for the publisher can save some positioning information in it, so that in the release of listening to make full use of, in the above code, I saved the list node reference, so that listeners add, locate, remove all in a constant time to complete.   Of course, you can also save the publisher's reference in Tocken, so that you can find a bug like "unblock a listener for an object that has never been listened to". Or, there's other information.

. NET event monitoring mechanism limitations and extensions