[Plug-in framework Exploration Series] establishes a delegated subscription publishing mechanism

Some time ago I had an idea to combine things that I felt interesting and convenient to develop at ordinary times and build a framework, which will make development more handy, unfortunately, as more things are added to it, they become more and more aware that this may not be what developers need, because it is too complicated. Yes, as a framework, it was just a little better. Later I got busy with my work, and I got stuck. When I went on a business trip to Guangzhou over the past few days and had nothing to do at night, I just picked up a module and said.

Messenger

During normal development, data transmission and processing can be completed through the event mechanism, but the event mechanism will introduce coupling. Of course, this coupling is often reasonable, however, in some cases, this coupling is not what you need. Too many dependencies may confuse you, and messenger is introduced to relieve this dependency. Please refer.

Figure 1. Unidirectional dependency between classes

Figure 2. Bidirectional dependency between classes

Figure 3. Dependency after the introduction of messenger

The concept of messenger comes from the mvvm foundation project.Source codeLater, we found that the Messenger is a good mechanism, and we designed our own messenger based on the actual situation.

As the name suggests, as a behavior transmitter here, messenger is responsible for receiving behavior subscriptions in advance and executing these behaviors as needed, that is, publishing.

Figure 4. Messenger class diagram

From the class diagram, we can see that messenger provides the ability to subscribe, UNSUBSCRIBE, and publish. Messenger has a built-in data structure used to store subscription behaviors. The storage structure is described as Dictionary <t, list <weakaction>. t indicates the semantic meaning of behavior and serves as the dictionary key, it corresponds to a group of behaviors, and each behavior is represented by weakaction. weakaction ensures the weakrefernce relationship between messenger and the Object Defining the behavior to avoid Memory leakage, this constitutes the behavior storage structure messagetoactionmap.

Figure 5. messagetoactionmap class diagram

Figure 6. weakaction class diagram

At last, messenger has the ability to subscribe and publish behaviors. To provide better flexibility, messenger is defined as a generic abstract type, and the specific messenger is extended by inheritance. Here, we have defined several typical messenger implementations:

Firgure 7. Messenger implementation

Ø generalmessenger

As a common implementation of messenger, generalmessenger inherits from messenger <Object> and is suitable for most scenarios.

Ø typemessenger

Typemessenger is more suitable for message-driven application scenarios. In distributed applications, messages are transmitted between systems, while message receivers often process messages differently based on different message types, for example, when the server receives a client login request, it will perform verification, and when it receives the logout request, it will release the resource. Of course, generalmessenger is fully competent for all these tasks, but typemessenger is more convenient. The data subscription and publishing mechanism mentioned later is implemented using typemessenger.

Ø onceoffmessenger

Onceoffmessenger is a special implementation of generalmessenger. Its most special feature is subscription behavior, which disappears after release and is suitable for processing one-time behavior.

To adapt to different development scenarios, messenger can create multiple instances. To implement the singletonmanager. getinstance mode, you can use singletonmanager. getinstance <t> to obtain the singletonmanager instance.

Firgure 8. singletonmanager class diagram

 
Typemessenger messenger = singletonmanager. getinstance <typemessenger> ();
 

 

Data subscription and publishing mechanism

The publisher is responsible for providing data, while the subscriber is responsible for consuming data, that is, processing data. Of course, the subscriber can also be a publisher, so that data can be reprocessed. To this end, the publishing interface and subscription interface are defined:

Firgure 9. Subscription and publishing interface class diagram

Standard Implementation of subscription and publishing is also provided:

Firgure 10. Subscription publishing standard implementation class diagram

We can see that both the subscriber and publisher use typemessenger to implement the subscription publishing mechanism.

In the subscriberadapter <t> subscribe method, the processing behavior of subscription T is handle:

 
/// <Summary> /// subscribe the message handler. /// </Summary> Public void subscribe () {messenger. subscribe <t> (new action <t> (MSG => handle (MSG )));}
 

 

Publish data in the onmessage and onmessageasyn methods of publisheradapter:

/// <Summary> // publish the message. /// </Summary> /// <Param name = "message"> the message. </param> Public Virtual void onmessage (Object message) {If (message! = NULL) {messenger. policyall (Message) ;}/// <summary> // publish the message asynchronously. /// </Summary> /// <Param name = "message"> the message. </param> Public Virtual void onmessageasyn (Object message) {If (message! = NULL) {messenger. policyallasyn (Message );}}
 

You can also publish data in a similar way in subscriberadapter <t>. Subscribers of this data type process the data.

This design method also draws on the concept of filters in the Apache Mina framework to transfer data in a filter chain. Each filter on the chain has the opportunity to process and reprocess the data. However, the data publishing behavior of the subscriber here can only publish data different from the current type. Otherwise, there will be an infinite endless loop. This behavior has been implemented by reloading the onmessage and onmessageasyn methods of publisheradapter.

Post

The event mechanism is convenient and simple to transmit data, but I personally think this method is more flexible and easier.

Download Code