Architecture Model and example of plug-in design (zz)

Address: http://dev.yesky.com/456/2485956.shtml

Plug-in design has been very popular in recent years, and eclipse has played an important role. When it comes to plug-in design, you can't help but think of Eclipse. In fact, plug-in design is not a new thing, as early as decades ago. X server is designed based on plug-ins. In addition to its core functions, all its extension functions and device drivers are added as plug-ins.

Plug-in-based design has many advantages: the extension function is removed from the framework, which reduces the complexity of the framework and makes it easier to implement the Framework. The extended functions are coupled with the framework in a very loose way. The two functions can be changed and released independently while the interfaces remain unchanged. Open plug-in interfaces to allow third parties to expand applicationsProgramFunctions of Alibaba Cloud. In addition, the open source and closed source can coexist in a set of software. Whether your plug-in is open source or closed source is up to you.

Plug-in-based design is not mysterious. On the contrary, it is simpler and easier to understand than a group of mud designs. Various plug-in-based architectures have their own characteristics, but their models are similar in terms of the overall architecture. Here we will introduce a simple model and provide several examples to inspire new users.

1. Basic Architecture

Plug-in-type design applications can basically be used for representation. Of course, this figure is a high-level representation, and the actual design will be more complex. We don't have to make it so complicated to elaborate on it for convenience.

An application consists of four parts: Application Framework, plug-in interface, plug-in, and public function library.

The application framework is responsible for the overall operation of the application. It is clear about the entire process, but does not know what to do for each process. It calls some plug-ins when appropriate to complete real functions.

The plug-in interface is a protocol that may be described by IDL, a header file, or a text description. The plug-in is implemented according to this Protocol and can be added to the application. Of course, for complex systems, there may be multiple plug-in interfaces with independent functions.

A plug-in is an entity that completes the actual functions and implements the required plug-in interface. Although what is implemented and how it is implemented, it is completely the plug-in's own freedom. In actual situations, there are still some restrictions, because the plug-in interface itself may be a limitation. For example, plug-ins that implement the compilation function naturally cannot implement a chat function plug-in.

A public function library is a group of functions or classes that can be called by application frameworks and plug-ins. It is usually an independent dynamic library (DLL ). The application framework itself is public, yesCodeA Method of reuse. But not all reusable code can be placed in the framework, especially the public code used by the plug-in, which will cause the plug-in to depend on the framework. It is a good method to extract the public code into an independent library.

In addition, it is worth noting that the plug-in interface is used. There are usually two types of plug-in Interfaces:

General Plug-In interface: This type of plug-in interface is generic, and you cannot see the function of this plug-in from the interface function. Its interface functions usually have these functions:

Init: used to initialize the plug-in. It is usually called when the plug-in is loaded.

Deinit: used for anti-initialization of the plug-in, which is usually called when the plug-in is uninstalled.

Run: Start the plug-in.

Stop: Stop the plug-in.

The plug-in determines the functions to be inserted into the init function. It calls the functions in the public function library and registers itself to a certain position in the framework.

Dedicated plug-in Interface: This type of plug-in interface is dedicated. You can get a general idea of its functions when you see its interface function descriptions.

The configuration information is usually used to add plug-ins. The configuration information can be a registry or a configuration file. You can also dynamically register the plug-in or place it in the specified location.

Here are several examples:

2. desktop design

Recently, the design and implementation of the desktop module have been completed. According to past experience, the desktop module is usually the most changing module, and spec is constantly adjusting the effect. Different customers require a personalized desktop until the product is quickly released, the desktop spec is constantly being modified. In addition, in the smart phone, desktop has a special position. Many things may be inserted into the desktop. Desktop is not only a hodgedge of various functions, but also a transfer station for some system messages.

This task is tricky, so be careful when designing it. The first thought was to adopt plug-in design to separate peripheral functions and simplify the implementation of the framework as much as possible.

Plug-ins: Each minimum function unit is a plug-in that can be visible, unavailable, or dynamically changed. Such as time, battery power, network connection, signal strength, new events (such as SMS, MMS, Emal, alarm, and missed calls), application shortcuts, left and right buttons, and other functional units for processing system events. Each plug-in is described using a. desktop, which complies with the freeyuntop.org standard.

The desktop framework includes the status bar, Start Menu, Operation bar, desktop area, event manager, and topic manager. The status bar, Start Menu, Operation bar, desktop area, and event manager are containers that hold various plug-ins. For visible plug-ins, you can have your own representation, or use a common representation.

Common function libraries: abstract classes, helper classes for implementing plug-ins, and other classes that may be shared.

Plug-in Interface: For invisible plug-ins, event processing is required. Visible plug-ins also require the rendering function.

3. Simulator Design

One colleague is responsible for designing a PC simulation environment for another platform. At my suggestion, he adjusted the architecture. The adjusted architecture is very simple and can be considered as a plug-in design. It consists of the following parts:

Application Framework: Responsible for basic simulator functions, such as analog keyboard and display devices and skin replacement functions.

Plug-in: it is a simulated platform, such as microwindow and corresponding mobile app. This method makes sense even though only one plug-in is often run during runtime. If you want to change to MiniGUI or another platform, the simulator does not need to be modified.

Common function library: it is used by the application framework to initialize some information and callback functions, and then called by the plug-in (microwindow). The plug-in uses it to implement drivers such as display and input.

Plug-in Interface: such as starting and stopping a simulated platform.

4. gimp

Gimp is a powerful graphic image editor. It is a typical plug-in-based design. It has been introduced as a plug-in design example in Unix programming art.

Application Framework: Gui

Plug-ins: complete various conversion and processing functions of images, such as blur, decimal spots, and color adjustment.

Public function library: Put it in libgimp. So.

Plug-in Interface: if you are interested in gimp, you can go to the official website to read more documents.