Callback-> observer mode-> reactor Mode

 

About callback:

Callback is the basis of the observer mode and the reactor mode.

In a word, callback is a two-way call mode. What does it mean? That is, the called party also calls the other party when called, which is called callback. "If you call me, I will call back ".
Let's take a look at this typical method of using callback:

Background 1: Class A implements the interface Ina

Background 2: Class A contains a reference to Class B.

Background 3: Class B has a method test (INA A) with the parameter Ina)

Object A of Class A calls the method B to input itself (because the parameter is Ina A), test (a) -- this step is equivalent to you call me.

Then, B can call the INA Method in the test method (reference to interface A has been passed in) -- this step is equivalent to I call you back.

Refer to the following code:

// The most basic callback mode implementation: public interface ina {public void callbacka ();} public Class A implements ina {// instance B with B = new B (); @ overridepublic void callbacka () {// todo auto-generated method stubsystem. out. println ("excute the method in Class A") ;}} public class B {public void test (INA A) {. callbacka ();} public void excuteb () {system. out. println ("excute the method in Class B ");}}

 

As you can see, Class A can use Class. B obtains B's instance to call the method in B. After execution, in the corresponding method of Class B, you can call back the method of A by passing in the parameter, this is critical.

Callback can also implement asynchronous operations. For example, if you have a complicated problem that cannot be solved, you can call your classmates and say that the problem can be solved, but it takes some time, you can't keep waiting there with your phone number. You will tell him your phone number and ask him to call you after solving the problem. The callback is reflected in the fact that your classmates call your number in turn.
Combined with the analysis above, you call your classmates [you call me]. After your classmates solve the problem, they call you to call you back [I call you back ].

Two key points:

1. Class A contains a reference of Class B as its attribute.

2. Class B needs to go back to class A's method and include a method. The form parameter of this method is a reference to Class.

3. The callback method must be implemented using interfaces, so that a can implement different types of callback methods through integrated interfaces.

To sum up, software modules always have certain interfaces. In terms of calling methods, they can be divided into three types: Synchronous calling, callback, and asynchronous calling. Synchronous call is a blocking call. The caller must wait for the execution of the other party to complete before returning. It is a one-way call. Callback is a two-way call mode, that is, the called party also calls the other party's interface when the interface is called. asynchronous call is a mechanism similar to messages or events, however, the calling direction is the opposite (note that this is the opposite of the previous example). When an interface service receives a message or an event, the customer is notified (that is, the customer's interface is called ). Callback and asynchronous call are closely related. Generally, callback is used to register asynchronous messages and message notifications are implemented through asynchronous calls. (It seems that only different purposes are actually similar) Synchronous calling is the simplest of the three, and callback is often the basis of asynchronous calling.

 

Observer mode (observer)

The observer mode is equivalent to the extended callback mode. In the observer mode, the observer is equivalent to a in the above example, and the observer is equivalent to B in the above example. The difference is that there are multiple observers. One observer can also be multiple.

Official definition of observer mode:

The observer mode defines a one-to-many dependency between objects, so that every time an object changes state, all objects dependent on it will be notified and automatically updated.

When the State of an observer changes, all objects dependent on it change.

Several roles in this mode:

Subject (the object interface to be observed), which specifies the unified interface of concretesubject.

Each subject can have multiple observers (implemented by adding the arraylist referenced by the observer to a specific implementation class or other similar methods, which is the key to implementing the callback method ), the observer is created before the observer, and the reference to the observer must be added to the arraylist of the observer so that the observer can be notified after the information of the observer changes. (Because the observer is created before the observer, and finally the observer is called to update the information, that is, the information created later, in turn, the object created first is called, so it is a callback)

Concretesubject (object to be observed)

Maintains a list of references to all specific observers. When the status changes, a notification is sent to all registered observers. (Callback and observer update are implemented by referencing the obversor in the list)

In terms of function, concretesubjec should include at least addobservor (add an observer) deletobservor (delete an observer) and updateobservor, and callback through updateobservoer to update the observer, or notify the observer to execute the corresponding transaction.

Observer (Observer Interface)

Specifies the unified interface of concreteobserver;

Defines an update () method, which is called when the state of the object to be observed changes.

Concreteobserver (Specific observer)

Maintain a reference to concretesubject. (You can reference concretesubject to call methods in concretesubject, such as adding and deleting operations. In this case, you do not need to generate a specific concretesubject class in the main function. Every observer contains the Add Delete method)

The specified status is synchronized with concretesubject to implement the observer interface and receive concretesubject notifications through the update () method. (The specific execution part of the callback)

For detailed analysis, see the following code. The obversor is written as witcher.

// Define the observer interface public interface iwatcher {public void Update (string Str);} // define the observer interface public interface isubject {public void add (iwatcher W ); public void Delete (iwatcher W); // modify the information in the Observer class public void Update (string Str);} public class concretewatcher implements iwatcher {private string STR; private int ID; public void setid (int id) {This. id = ID;} public int GETID () {return ID;} // constructor public concretewatcher (string STR, int ID) {This. STR = STR; this. id = ID; system. out. println ("the STR is created:" + STR + this. getclass (). hashcode () ;}@ override public void Update (string Str) {// todo auto-generated method Stub this. STR = STR; system. out. println (this. GETID () + "the STR is updated:" + Str );}} public class concretesubject implements isubject {// The list of queues containing an observer is the reference arraylist of the observer queue <iwatcher> List = new arraylist <iwatcher> (); @ override public void add (iwatcher W) {// todo auto-generated method stub list. add (w) ;}@ override public void Delete (iwatcher W) {// todo auto-generated method stub list. remove (w);} // The callback is in this place @ override public void Update (string Str) {// todo auto-generated method stub // because list is an attribute of its own class, you do not need to pass it through the method. // here is a method in the callback watcher to update for (iwatcher w: list) {W. update (STR) ;}} package COM. designpatten. observer; public class test {// generate three observers public static void main (string [] ARGs) {concretewatcher a1 = new concretewatcher ("watcher1", 1 ); concretewatcher a2 = new concretewatcher ("watcher2", 2); concretewatcher a3 = new concretewatcher ("watcher3", 3 ); // generate an abstract topic concretesubject sub = new concretesubject (); sub. add (A1); sub. add (A2); sub. add (A3); sub. update ("update the information") ;}// execution result/* The STR is created: watcher11580958233the STR is created: watcher21580958233the STR is created: watcher315809582331 the STR is updated: update the information2 the STR is updated: update the information3 the STR is updated: update the information */

 

 

Reactor)

Reactor pattern is very similar to observer pattern in this respect: When a subject changes, all dependent bodies are notified. However, the observer mode is associated with a single event source, while the reactor mode is associated with multiple event sources.

Reactor pattern is an event design pattern that processes service requests and submits them to one or more service handlers concurrently. When a request arrives, the Service handler uses a multi-channel allocation policy, then, these requests are synchronously distributed to the relevant request processing program.

The observer Patten only listens to a fixed topic. In the reactor Patten, it is equivalent to the subject implementation instance that simultaneously contains different initrylist corresponding to one event. Each event is triggered and uploaded to the subject, the classes referenced in the corresponding arraylist will be updated (the so-called registered events)

In the reactor mode, the document often mentions that a hook method is the hook method, which is part of the template mode. For details, refer to the links listed later.

Here is a brief summary:

From the perspective of template mode, methods are divided into three types: Specific methods, abstract methods, and hook methods.

1. The specific method is the most common and common method we usually write.

2. abstract methods are abstract methods in Java, which are so-called inheritance. This is also common. Several functions appear in the same sequence during execution, but each step may have different implementations in the subclass, so it can be inherited directly. DI can implement different abstract classes, this core idea is to provide an algorithm framework in the parent class. Child classes can only follow this framework, but the implementation of each step may be different. The most typical is the sort function. You can customize the sorting rules for each sort. This may be designed for different fields, but the entire implementation of the sort function is a big step, it is completely fixed.

3. The Hook method is actually the opposite. Using the Hook method, subclass can affect the execution process of the parent class to a certain extent. The return result of the hook method is usually a bool variable, A step in the parent class (template method) is usually placed in the IF statement. If the Hook method returns true, the execution is performed. If the return value is false, the execution is not performed. In the subclass, You can overwrite the Hook method based on the actual situation and modify its default return value to determine the execution process of the appropriate template method, the subclass affects the execution process of the parent class (template method.

 

References:

Http://1025250620.iteye.com/blog/1378538

Http://daimojingdeyu.iteye.com/blog/828696

Http://blog.csdn.net/fengxinze/article/details/7319059 (this is a translation version)

(It must be that the logserver object must be generated before it can be registered to the initial dispatcher for callback. To be honest, the get_handler In the example is still a bit dizzy and recorded here first)

Template Method Mode

Http://blog.csdn.net/lenotang/article/details/2911246

Http://blog.csdn.net/lovelion/article/details/8299927

Other network Materials