Shulou(Shulou.com)06/03 Report--

This article introduces the knowledge of "how to write the limitations and extensions of .NET event monitoring mechanism". In the operation of actual cases, many people will encounter such a dilemma. Next, let the editor lead you to learn how to deal with these situations. I hope you can read it carefully and be able to achieve something!

The specific analysis is as follows:

Net regards "event" as a basic programming concept, and provides very beautiful syntax support. Comparing the following C# and Java code, you can see the difference between the design ideas of the two languages.

The copy code is as follows:

/ / C#

SomeButton.Click + = OnSomeButtonClick

The copy code is as follows:

/ / Java

SomeButton.addActionListener (

New ActionListener () {

Public void actionPerformed () {

...

}

});

We use a lot of events in our software to decouple listeners and publishers, but we also encounter some limitations. I'd like to share one or two with you here. One is that the order of calls of the listeners cannot be guaranteed, and the other is the efficiency of monitoring and relieving the listeners when there are many listeners.

Call order of event listeners

The event listening mechanism of .NET does not explicitly guarantee the order of calls of listeners, but sometimes we require that the processing order between different components be guaranteed. For example, in our software to implement user interaction in a way similar to the interpreter pattern, a component called interaction source is responsible for dispatching events on UI controls to a group of components called interactors, which are given the opportunity to handle events in order of pre-determined priority, and only when the high-priority interactor does not handle the event, the low-priority component can perform further processing. In this way, we can reuse different business functions by organizing them in different order. For example, reuse some basic functions such as view zooming, panning, menu processing, etc.

In the above scenario, how to ensure the order of event processing between interactors becomes very important. Of course, if you look at the source code of MulticastDelegate, you can see that in the current implementation, each listener still has a certain call order. But on the one hand, this is an implementation detail, which may change in the future; second, if different listeners are in different modules, it is difficult to rely on this implementation to ensure the order of calls between them.

Here we draw lessons from the way of handling events through the interface in Java, and receive a parameter indicating priority while adding listeners, so that we can explicitly maintain the order of listeners, as shown in the following code. We define a method for each UI event in the IInteractor interface, and let InteractSource be responsible for converting the event on the control into a call to the corresponding method in the interface.

The copy code is as follows:

Public class InteractSource

{

Public void AddInteractor (int priority, IInteractor interactor)

{

}

}

Public interface IInteractor

{

Public void OnMouseDown (MouseEventArgs e)

{

}

......

}

Efficiency of adding and removing listeners

MulticastDelegate is the implementation behind our usual event mechanism, and you can see from its source code that it internally uses arrays to hold references to individual listeners. This creates a problem-when there are a large number of listeners for an event, the efficiency of adding and removing listeners becomes very inefficient. Take removal as an example, for events with N listeners, it takes an average of 2 comparisons to determine the location of the listeners, and additional array collation operations. In order to solve this situation, we first try to define the add and remove logic of events, and internally try to use dictionaries, hashes and other ways to store, but facts have proved that although the two have advantages in terms of time complexity, but its actual efficiency still does not meet the requirements.

At best, there is a data structure that can add and remove listeners in constant time, and you may have thought of it as well-a two-way linked list.

You may have thought of it again-adding and deleting in a two-way linked list is a constant time, but the search is still O (n) complexity.

The design in the form of an interface once again shows its flexibility, and we can design the event publisher in the following form (schematic code):

The copy code is as follows:

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

}

}

In this class, a two-way linked list is used to store the listeners that have been added, and each time the AddListener method is called, the added linked list node is saved to a Token and returned. The listener needs to save this token and use it to release the listener. Of course, the listener can ignore what a token is, just as a subway ticket is always just a ticket, and we don't care what information it contains. However, for publishers, it is possible to save some location information in it, so as to make full use of it when unlistening. In the above code, I saved the reference of the linked list node. Thus, the addition, positioning and removal of listeners are completed in a constant time.

This is the end of the content of "how to write the limitations and extensions of the .NET event listening mechanism". Thank you for reading. If you want to know more about the industry, you can follow the website, the editor will output more high-quality practical articles for you!

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.