本文讨论一种简单却有效的插件体系结构，它使用C++,动态链接库，基于面向对象编程的思想。
首先来看一下使用插件机制能给我们带来哪些方面的好处，从而在适当时候合理的选择使用。
1， 增强代码的透明度与一致性：因为插件通常会封装第三方类库或是其他人编写的代码，需要清晰地定义出接口，用清晰一致的接口来面对所有事情。你的代码也不会被转换程序或是库的特殊定制需求弄得乱七糟。
2， 改善工程的模块化：你的代码被清析地分成多个独立的模块，可以把它们安置在子工程中的文件组中。这种解耦处理使得创建出的组件更加容易重用。
3， 更短的编译时间：如果仅仅是为了解释某些类的声明，而这些类内部使用了外部库，编译器不再需要解析外部库的头文件了，因为具体实现是以私有的形式完成。
4， 更换与增加组件：假如你需要向用户发布补丁，那么更新单独的插件而不是替代每一个安装了的文件更为有效。当使用新的渲染器或是新的单元类型来扩展你的游戏时，能过向引擎提供一组插件，可以很容易的实现。
5， 在关闭源代码的工程中使用GPL代码：一般，假如你使用了GPL发布的代码，那么你也需要开放你的源代码。然而，如果把GPL组件封装在插件中，你就不必发布插件的源码。
介绍
先简单解释一下什么是插件系统以及它如何工作：在普通的程序中，假如你需要代码执行一项特殊的任务，你有两种选择：要么你自己编写，要么你寻找一个已经存在的满足你需要的库。现在，你的要求变了，那你只好重写代码或是寻找另一个不同的库。无论是哪种方式，都会导致你框架代码中的那些依赖外部库的代码重写。
现在，我们可以有另外一种选择：在插件系统中，工程中的任何组件不再束缚于一种特定的实现（像渲染器既可以基于OpenGL,也可以选择Direct3D）,它们会从框架代码中剥离出来，通过特定的方法被放入动态链接库之中。
所谓的特定方法包括在框架代码中创建接口，这些接口使得框架与动态库解耦。插件提供接口的实现。我们把插件与普通的动态链接库区分开来是因为它们的加载方式不同：程序不会直接链接插件，而可能是在某些目录下查找，如果发现便进行加载。所有插件都可以使用一种共同的方法与应用进行联结。
常见的错误
一些程序员，当进行插件系统的设计时，可能会给每一个作为插件使用的动态库添加一个如下函数类似的函数：PluginClass *createInstance(const char*);
然后它们让插件去提供一些类的实现。引擎用期望的对象名对加载的插件逐个进行查询，直到某个插件返回，这是典型的设计模式中“职责链”模式的做法。一些更聪明的程序员会做出新的设计，使插件在引擎中注册自己，或是用定制的实现替代引擎内部缺省实现：
Void dllStartPlugin(PluginManager &pm);
Void dllStopPlugin(PluginManager &pm);
第一种设计的主要问题是：插件工厂创建的对象需要使用reinterpret_cast<>来进行转换。通常，插件从共同基类（这里指PluginClass）派生，会引用一些不安全的感觉。实际上，这样做也是没意义的，插件应该“默默”地响应输入设备的请求，然后提交结果给输出设备。 [Page]
在这种结构下，为了提供相同接口的多个不同实现，需要的工作变得异常复杂，如果插件可以用不同名字注册自己（如Direct3DRenderer and OpenGLRenderer）,但是引擎不知道哪个具体实现对用户的选择是有效的。假如把所有可能的实现列表硬编码到程序中，那么使用插件结构的目的也没有意义了。
假如插件系统通过一个框架或是库(如游戏引擎) 实现，架构师也肯定会把功能暴露给应用程序使用。这样，会带来一些问题像如何在应用程序中使用插件，插件作者如何引擎的头文件等，这包含了潜在的三者之间版本冲突的可能性。
单独的工厂
接口，是被引擎清楚定义的，而不是插件。引擎通过定义接口来指导插件做什么工作，插件具体实现功能。我们让插件注册自己的引擎接口的特殊实现。当然直接创建插件实现类的实例并注册是比较笨的做法。这样使得同一时刻所有可能的实现同时存在，占用内存与CPU资源。解决的办法是工厂类，它唯一的目的是在请求时创建另外类的实例。如果引擎定义了接口与插件通信，那么也应该为工厂类定义接口：
template<typename Interface>
class Factory {
virtual Interface *create() = 0;
};
class Renderer {
virtual void beginScene() = 0;
virtual void endScene() = 0;
};
typedef Factory<Renderer> RendererFactory;
选择1: 插件管理器
接下来应该考虑插件如何在引擎中注册它们的工厂，引擎又如何实际地使用这些注册的插件。一种选择是与存在的代码很好的接合，这通过写插件管理器来完成。这使得我们可以控制哪些组件允许被扩展。
class PluginManager {
void registerRenderer(std::auto_ptr<RendererFactory> RF);
void registerSceneManager(std::auto_ptr<SceneManagerFactory> SMF);
};
当引擎需要一个渲染器时，它会访问插件管理器，看哪些渲染器已经通过插件注册了。然后要求插件管理器创建期望的渲染器，插件管理器于是使用工厂类来生成渲染器，插件管理器甚至不需要知道实现细节。
插件由动态库组成，后者导出一个可以被插件管理器调用的函数，用以注册自己：
void registerPlugin(PluginManager &PM);