Learning plug-in Architecture (ii) _ Plugin

The first address is here:

http://blog.csdn.net/xuddk727/article/details/10076409

Thank all friends for their support, but also thank a lot of friends who put forward valuable opinions.

First answer the first article why not COM. The author is going to dig a big pit to write a series of articles, so from the author think the earliest plug-in architecture way to speak.

Second, on the title, why is the Learning plug-in architecture. In this series, the end result will not be a complete architecture, because the industry is so diverse that the details are completely different. This series of articles is just a list of the problems and solutions that I think are needed in the plugin architecture. Of course, limited to the author level, the scheme will certainly not be the best, which may be a lot of mistakes, you are welcome to correct me. Some of these programs include various data types of interaction, multi-language support, the author only to achieve a simple program, as an open topic, but also welcome everyone to participate.

All the code, the author will only be to achieve the most basic functions as the principle of the way presented to everyone, so it is along with the article go, welcome to make sharp criticisms:).

Why use com: the author of the Unit's Product research and development Center only No. 230 people, while other departments will be C #, Java, there are hundreds of people, known to recruit C + + personnel difficulties, so support multi-language is imperative. C interface is also possible, but many need to achieve their own, the workload is very large. Well, actually I don't have C # ...

Seriously, the original reason not to say, to COM if unfamiliar friends can go to the VC knowledge Base to see the teacher Yang's tutorial. This tutorial is still just a simple way to show a COM authoring plug-in, involving data sharing and messaging that will be reflected in the next article.

We'll sort through the whole process: enumerate and load all compliant plug-ins--"Find and invoke the plugin according to the corresponding command-" uninstall all plugins at the end. So we made the following design:

A plug-in runtime (plug-in management Class) that is responsible for loading, invoking, and uninstalling Plug-ins (corresponding to the Pluginmgr project).

An EXE empty frame, by which it carries the plug-in runtime.

Several plug-ins, waiting to be invoked.

Among the knowledge points involved, the first is how to enumerate all the types of plug-ins that fit. COM itself provides a kind of thing called category, through which we can easily enumerate all the plug-ins. Details can be to the VC knowledge Base to understand:

Http://www.vckbase.com/index.php/wv/159.html

In C + +, inheritance makes it easy to implement extensions, which can be accomplished by implementing interfaces in ATL. In the example code, the plug-in completes the inherited work by implementing the Ipluginobject interface, allowing Ipluginappmgr to invoke all Plug-ins only if the Ipluginobject interface is invoked at runtime. Because it does not involve data sharing and messaging, ipluginobject I just did a simple design that still mimics the first section, which contains only the name of the module and the execution of two interfaces. Here's a bit of personal opinion: I think the mature plug-in itself should contain loading initialization, uninstall, implementation and interaction, test everyone design ability time to:).

PS: Because the time is quite hurried, did not do how many introduction, just will some simple knowledge point through the link to send to everybody, everybody should see, sorry.

source code address;

http://download.csdn.net/detail/xuddk727/6000759