There is always a certain interface between modules, which can be divided into three categories: synchronous invocation, callback, and asynchronous invocation. Synchronous invocation is a kind of blocking call, which is also often used in writing programs, and callback is a two-way invocation pattern, that is, the called interface will also call the other side of the interface, this sentence may be a bit around, and so on, and so on, and so on. Asynchronous invocation is a similar message or event mechanism, Solve the problem of synchronous blocking, for example: a notice B, they walk each road, do not affect each other, do not like synchronous call, a notice B, must wait until B after the end, a just continue to go. Callbacks are fundamental to asynchrony, so the following emphasis is on the callback mechanism.
For the moment, let's not discuss some of the terminology and operating mechanisms of callbacks, first of all, why is there a callback call? The emergence of synchronous and asynchronous mechanisms do not need to say, we know that the callback mechanism why it appears? In our real life, there is the following scenario: a boss (upper module) is busy, he has no time to stare at the staff (the lower module) to work, and then he tells his employees, after the current events, to tell him the results of the work. This example is actually a callback + asynchronous example, another example, a programmer wrote a program A, which reserved the callback function interface, and encapsulated the program, Programmer b Let a call its own program B in a method, so he through the interface in a called back to the method in B, You may be indefinitely here, and you will continue to explain why the callback occurred. Next we turn the above example into code, and see many people on the net finally confusing async and callbacks, so the example does not add an asynchronous call. (Note: Callbacks are not a solution to the problem of long call times, it's asynchronous!) )
The specific implementation of the callback:
1.class A,class B
2.class a Implementation interface callback
3.class B has a function with a parameter of callback interface type
4.class a runtime invokes a function in class B to pass in the parameter itself
5.class B has obtained a, it can be recalled at any time the method of the callback interface implemented by a
Start by creating a callback interface that tells the boss how to find his way through the job: Leave the boss's office address:
/** * Callback interface * @author */Publicinterface callbackinterface {public void execute ();}
Create callback object, is the boss himself, because the staff to call him after the work, so the boss must implement callback interface, or where employees go to find the Boss?
/** * Boss * * @author Sun * */public class Boss implements Callbackinterface {@Overridepublic void execute () {SYSTEM.O Ut.println ("received ~" + system.currenttimemillis ());}}
Create the control class, which is the employee object, he must hold the boss's address (callback interface), even if the boss changed stubble and stubble, the office is unchanged, always find the corresponding boss.
/** * Employee class * * @author Sun * */public class Employee {private callbackinterface callback;public void Setcallbackinterfa CE (callbackinterface callBack) {this.callback = CallBack;} Workers work public void dosomething () {//1. Start working. for (int i = 0; i < i++) {System.out.println ("" "+ i +") It's done! ");} 2. Tell the boss to finish Callback.execute ();}}
Test Class Code:
/** * * @author Sun * */public class Client {public static void main (string[] args) {Employee employee = new Employee ( )///The callback object (upper object) is passed in, register Employee.setcallbackinterface (new Boss ());//Open Controller Object run Employee.dosomething ();}}
In this example, you can compare it with the example of programmer A and programmer B.
Looking at the example above, some people may think that this is not interface-oriented programming? How can it be a callback, and you think about it, our interface-oriented programming call relationship? In layer three, when the business layer calls the data layer, it does not need to pass the business layer itself to the data layer, and this is an upper layer call the underlying relationship, such as when we use the framework, the general direct call to the framework provided by the API can be, but the callback is different, when the framework does not meet the requirements, We want the framework to call its own class method, how to do it? There's no way to change the frame. Many excellent frameworks are almost all related interfaces, we just need to implement the relevant interface, we can complete the registration, and then let the framework to call our own class at the appropriate time, remember when we use struts, when we write the action, we need to inherit the action class, Then implement the Execute () method, write our own business logic code in the Execute () method, and complete the processing of the user request. This makes it possible to guess that the framework and the container provide a large number of callback interfaces to suit individual customization.
I wonder if the above example is understood? We can now imagine the difference between filter and interceptor, the biggest difference between the two is that filter is based on a callback function that requires container support, no container is unable to callback the Dofilter () method, Interceptor is based on the reflection mechanism of Java, and is not related to containers. Does it confuse reflection with callbacks? See my blog of the Java Dynamic Agent, "Take this long, complement the short----AOP (proxy mode)."
In short, to be clear, the first thing is to understand the reason for the callback function, that is, the application of the scene, in order to clear the callback mechanism, otherwise less effort.
Reprinted from: http://blog.csdn.net/bjyfb/article/details/10462555
Java Callback mechanism parsing