Discussion on events and Delegation

Let's take a look at a big bull's example of calling a neighbor to collect clothes in the rain. It seems to be instantly cheerful!

Using system; using system. collections. generic; using system. LINQ; using system. text; namespace accept clothes {Public Delegate void mydelegate (); // first define a delegate class me // I {public void pickupclothes () // I have a method for collecting clothes {console. writeline ("My clothes are retained! ");} Public void phoneneighbor () // I also have a method to call a neighbor {neighbor plmm = new neighbor (); // assume that the neighbor is a beautiful mm ~ Plmm. getphone + = new mydelegate (pickupclothes); // tell her how to accept clothes... (Bind a pickupclothes method to the getphone event) plmm. doit (); // just do it ...}} class neighbor // neighbor {public event mydelegate getphone; // The neighbor has a call answering event public void doit () // The neighbor must have a way to handle the event {If (getphone! = NULL) // if I didn't say anything when I called {getphone (); // do what I said! }}} Class program {static void main (string [] ARGs) {console. writeline ("It's raining! "); // It's raining... Me me = new me (); // instantiate a me. phoneneighbor (); // call a neighbor }}}

 

Experts said:

Your "example" does not seem to have many problems, but I think it may be that you did not explicitly express your habits.

For example, we put a map in our program window, and then mark the travel schedules and routes that we care about on this map. Then Map Processing is related to annotation (because it has this capability, we can introduce it as a service to our program ), our program may receive notifications about user labeling at any time. It's not what you wrote "justdo ".

Remember, it's not that you do the plmm, but that she does you. You then return the returned parameters to her after the event processing is complete. It's not you do her, it's her do you!

According to your writing and the above map tagging program, your understanding is similar to saying that when our program wants to capture users' freedom to mark travel schedules and routes on a map, we "call a method of the map service", so this method suspends all programs, and then the user performs a series of annotation actions, then we call this map method to return the behavior result to the program. But interactive programs are not designed like this at all! It is impossible for you to design a map in the "input-output" way similar to a computing method.

Your code has this kind of preference. If you design the interaction program process in this way, you will not be able to make the interaction program a little smoother. You need to learn program design again.
 
 
 

Most of the time, we use the service, instead of giving her an instruction to "accept clothes. Why does the other party only have that empty behavior? The other party actually has complete and rich behaviors. she exposes a small number of event interfaces. When she is hungry, we take her out for dinner. When she is tired, we give her a hammer leg, she's sleepy. Let's talk to her about sleep programming technical terms ..... we listen to the behavior of the other party, not because the other party only shows the simple meaning of your code. We use a service and register to listen to its events because it will actively send Event Notifications of various behaviors at any time, then we process such event notifications and make necessary modifications to the event parameters (so that the service can receive feedback ).

In your example, although the Code is not very problematic, there may be a risk of "simplification and misuse" when designing events.

 

Callback, which is very basic programming. This callback mechanism has been available for programming (machine language and assembly language). For example, in large programs in assembly language, there is always a "call table" to layer different levels of systems, the underlying layer is the code that uses the form-driven method to increase the level back and forth. For example, hardware and software combined with machine interruption-software callback mechanism. Microsoft's programming tools have been event-driven since Windows started. Events are the basic mechanism for driver development. If you do not understand the event-driven mechanism, there will be a lot of tedious so-called "design patterns", or strange so-called "injection methods ".

Assume that a depends on B, and a acts as the customer and B as the service. If B has some messages to notify ajiu, the event notification can be used. For example, a Textbox Control was developed before your program. To extend the function of a Textbox Control instance, you must register the callback Processing Method of the Textbox Control, this allows you to expand its functions.

In addition, many customer programs can register the same event processing for the same service, and the service will call these methods round-robin.

However, the textbox Implementation sets a delegate event interface where the customer needs to be notified, so you can register a processing method that can be called. However, the event interface is strongly typed. The customer can only register the event processing method where the service opens the callback. If it allows arbitrary injection, the client will modify it at will, so the event mechanism is certainly much more reliable than AOP.

This is the basic mechanism of programming design.

Events are the basic mechanism for driver development --> events are the basic mechanism for Windows program development.

 

A delegate is a variable pointing to a method, and an event is a variable pointing to a delegate,

 

Bytes ------------------------------------------------------------------------------------

Delegate:
A variable type, which is called a delegate.

Event:
Instantiate a variable with this variable type. This variable is an event,

For example:
For example, if I use an int table as the method type,
That:
List <int>
Is the delegate.

And:
List <int> EV
EV in is an event,
Ev can have the add method, which is equivalent to event registration,
The Remove Method is equivalent to canceling registration.

When an event is executed, you only need eV ();. ---- It is equivalent to editing EV with foreach and calling each element of it.
 

Of course, the method type is not what I mentioned above,
Is as follows:
Method
Public void dosomethings (Object sender, eventargs E)
{}
The following statement delegates, ---- is the type of the above method

Public Delegate void delegate _ the type of the above method (Object sender, eventargs E); Delegate _ the type of the above method // is the method type

 

Public event Delegate _ the type EV of the above method; EV in is the event.

Register as follows

Ev + = new BK (dosomethings); // The Registry event, that is, when the event variable is called by its administrator, the registration method is executed, and the parameter is still transmitted, but there is no returned value.

 

 

The above content is from the Forum

Sorting: Duan Liqing