Plug-in system [4]-relational model-universal observer

The plug-in independence and dependency between the plug-ins are issues that must be addressed by the plug-in framework.

The independence is related to the Division granularity of the plug-in. Each plug-in is implemented as a DLL, which ensures the independence of the plug-in physically. The dependency between plug-ins is a more complex problem to be solved.

I. Observer Mode

We split the system into a series of collaborative classes. common side effects are that consistency between related objects needs to be maintained. However, we do not want to make all kinds of Close coupling to maintain consistency, because this reduces their reusability. (Reference from gof's design patterns)

At a fixed time point of the subject, the observer update notification will be called to notify the observer.

2. Observer's evolution 2.1 increases observation interest

The above only takes into account a simple situation, that is, there is only one interaction between the classes that collaborate with each other. However, the interaction scenario in the system is not just one. That is to say, the observer type (Interface) is not just one, but two or more.

At this time, we cannot simply store a fobservers list in the subject. We may need to store multiple fobservers. For example:

Alternatively, we can use an observer List Manager to manage so many observer interfaces:

2.2 PUSH model vs PULL model

From the above description, we can see that the information required by the observer is transmitted to the observer through the update method, which is the "push" mode. Another case is that the observer takes the information from the target after receiving the update notification. This is the PULL mode ". The push mode and pull mode indicate the role that triggers the update.

2.3 unified management of the observed list

If you need the observer to trigger the update, you need to save the reference to the target in the observer so that the observer can call the notify method when appropriate. At the same time, in a system, both the target and the observer are relative concepts. For a module, some applications exist as the target, while others exist as the observer.
After analysis, the observer manager can be processed in a unified manner as a registration center between the target and the observer.

Iii. General Relationship-subject and object 3.1 Relationship manager

The current observer model is quite different from the existing observer model. The observer registration center stores not only the observer list, but the "target-Observer" pair, several corresponding observers can be found through a target. As shown in:

A link is the description of interaction between objects. In our system, objects refer to interfaces. Any module can find a type of interface associated with itself, and the module interacts with each other through the interface. The essence of the Registration Center is the interaction between management modules, which exist as a relationship manager.

In a "target-Observer" interaction, the target triggers the interaction process and the observer accepts the information. An interaction can be divided into three parts: "subject-relation-object", which is equivalent to the "subject-object" structure in the syntax. As for the module as the subject, the module as the object, it depends on the definition in the relationship manager.

3.2 link Registration

In observer mode, we need to call attach and detach to register and cancel the observer. After the concepts of the object and the observer are further abstracted into the relationship between the object, we no longer need to call the attach and detach methods of the target. Everything is the responsibility of the Relationship manager.

Provide the register and unregister functions in the relationship manager to accomplish similar functions. Use findrelated to find the observer list. In this way, the functions in the Observer mode can be implemented and the observation points can be conveniently expanded.

Iv. application scenarios

Two important problems to be solved in the plug-in system: independence and dependency. These two features are in conflict, but the isolation between modules can be effectively realized through interfaces. When there are only a dozen modules in a system, interaction is not a big problem, but when there are hundreds of modules in the system, the interaction between modules needs to be managed.

The link mode is an object interaction mode. The link mode described above is a kind of development based on the link mode. It is suitable for managing the interaction between plug-ins in the plug-in system. And these relationships can be customized. The specific customization method is closely related to the actual business.

Currently, the relational model has been applied in the plug-in system, but I think this idea can be used in other systems.