插件

PluginHelper PluginHelper是另外一个帮助类，用于帮助插件开发者编写插件胶水代码。下面是它的实现：

ActorBaseTemplate ActorBaseTemplate是混合实现的核心。插件开发者需要继承这个类，实现 C++ 的IActor接口，插件则通过 C 接口与插件管理器交互，这样才能保证二进制兼容。插件开发者则不应当看到这个 C 接口，C 接口对于插件开发者应当是完全透明的。

在前面的章节中，我们详细讨论了 C++ 二进制兼容性的困难。然后，我们引入了插件框架的设计和实现，讨论了插件的生命周期、跨平台开发的注意事项以及如何根据业务模型设计基于插件的系统等等。下面，我们将讨论如何使插件通过 C 接口与应用程序交互，同时还能允许开发者使用 C++ 接口开发插件。最后，我们将开始 RPG 游戏的编码，同样会基于这个插件模型。我们将介绍游戏的概念、如何以及为什么这么设计接口，最 ...

ActorInfoContainer用于管理ActorInfo对象集合。它实现了 C++ 接口IActorInfoIterator，在其内部保存集合索引。当调用 next() 的时候，返回该索引位置的对象；如果索引大于集合元素数目，则返回 NULL。当调用reset()时，则将索引置 0。当然，索引的初始化为 0。

错误处理 错误处理在基于插件的 C++ 系统中与普通系统有所不同。你不能简单的在插件中抛出异常，然后由应用程序去处理它们。这是因为我们前面讨论过的二进制兼容的问题。如果插件使用与编译系统的同样的编译器编译，这种实现还可能正常。但是，你不能强制插件开发者使用与你一样的编译器。你可以使用 C 风格的返回错误码，但是这不符合我们的 C++ 插件框架的设计理念。插件框架的主要设计目标之一就是，允许插件开发 ...

本章节将开始讨论如何开发跨平台的 C++ 插件。 跨平台开发 C/C++ 的跨平台开发相当复杂：数据类型不同，编译器不同，操作系统 API 也不同。跨平台开发关键是封装平台差异性，让你的应用程序仅关注于业务逻辑。如果应用程序使用了与平台相关的代码，我们就需要添加很多#ifdef OS_THIS或者#ifdef OS_THAT这样的宏。这是你必须注意的。解决跨平台问题的一个最佳实践是，将平台相关代码 ...

插件系统组件 本章节主要描述通用插件框架的主组件及其作用。 DynamicLibrary DynamicLibrary组件是一个简单的跨平台 C++ 类。它使用 dlopen/dlclose/dlsym 系统调用（UNIX 以及 OS X）和 LoadLibrary/FreeLibrary/GetProcAddress API 调用（Windows）。

注册对象 现在，球已经在插件手上了（在PF_initPlugin中）。如果版本正确，插件管理器应当已经注册了所有支持的对象类型。注册的目的是提供类似PF_CreateFunc和PF_DestroyFunc这样的函数，以便以后用于创建和销毁插件对象。这种安排允许插件自己控制所管理对象的实际创建和销毁操作，包括资源管理等（如内存），而由应用程序控制所有的对象及其生命周期。当然，插件也可能使用单例模式， ...

在前面的文章中，我们讨论了问题的细节、多种解决方案，最后大体引入了插件框架。下面，我们将继续架构的描述、插件生命周期的管理以及插件框架的具体实现细节。注意，我们的代码可能仅仅是接口层次的，不会涉及更深入的实现。 基于插件系统的架构 基于插件的系统可以分成三个部分，这三个部分都是松散耦合的：使用其对象模型的主系统或主应用程序，插件管理器和插件。插件需要符合插件管理器的接口和协议，并且需要实现对象模型 ...

编程语言的支持 在前面的章节中，我们已经了解到，如果你能够使用编译器令应用程序和插件的虚表匹配，那么就可以保持 C++ 虚表级别的兼容性；或者你可以使用 C 级别的兼容性，然后就能使用不用的编译器去构建系统，但其限制在于你只能编写纯 C 应用。这样的话，你就不能够使用前面我们在例子 IActor 中看到的那种优雅的 C++ 接口。