游戏服务器平台与动态库.ppt

背景 从桥模式谈起 桥模式到平台 桥模式的一个变体 Module与动态链接 游戏平台服务器的设计 总结 背景 设计一个游戏平台服务器 它统一管理并提供共有服务给具体的小游戏 每个小游戏是一个模块，即动态库 每开发一个小游戏，只要写一个模块挂到平台服务器即可 从桥模式谈起 桥（Bridge）模式定义 ：将抽象和实现划分开来,各自独立,但能动态的结合 桥（Bridge）模式意图：将抽象部分与实现部分分离，使它们都可以独立的变化 UML结构图： 从桥模式谈起 代码示例 先定义Abstraction和Implementor 从桥模式谈起 在定义ConcreteImplementorA和ConcreteImplementorB RefinedAbstraction 从桥模式谈起 在桥模式中，抽象可以根据自己的需要来选择实现，这十分很有用，许多需要有多选择性的设计都可以采用这样的方式。例如定时器设计中，就可以采用这种方法，定义了定时器的抽象接口，然后按抽象接口的定义，我们可以实现十字链表定时器、堆定时器等，运用的时候，开发人员根据自己的需要选择用哪种定时器。 桥模式到平台 提供公有服务的服务器我们称之为平台性服务器。 平台性服务器分两类： 1、提供外部公有服务 2、提供内部共有服务 桥模式到平台 对我们所设计平台而言，它必须有动态选择模块的能力，而这正是桥模式说擅长，所以我们很容易把UML类图中左边部分，即Abstraction部分看成是平台，将右边部分，即Implementor部分看成模块，那对应后的UML类图变成： 将Platform、Module的关系用桥模式表达后 1、Platform可以动态灵活的选择Module，客户可以根据需要选择Module。 2、可以将开发分成两部分，一部分是Platform的开发，一部分是Module的开发，只要遵循PlatformInterface和ModuleInterface就可以。 3、Platform完成后，只要遵循ModuleInterface的接口定义，开发人员可以开发各自的Module，提供给Platform使用而不会造成什么麻烦。 但是，我们还遗漏一点，平台提供公有接口的能力怎么体现呢？ 现在我在Platform新增一个给客户端发包的公有接口，提供给Module使用。但却发现具体Module没有途径使用Platform的这个接口，所以我们需要进一步的思考，将设计做一些修改。 再次回个头在看看再继续看看桥模式的UML图，发现Platform是通过module_来调用Module已知接口，那么用相同的方式，Module是不是也可以用指针来调用Platform提供的公有接口？答案是可以的。 至此，Platform就可以提供公有接口给Module使用了，Platform也可以调用Module的已知接口，哈，well! 桥模式修改后的这个变体很有意思，就像是两个桥模式复合而成的，有对称性。双桥模式（double-bridge）或者对称桥模式（symmetry-bridge）？ 为什么要使用动态链接？ 1、把Platform和Module在物理上进行分割 2、Platform和Module只通过抽象接口关联 动态链接的ABI（Application Binary Interface）特性，只要承诺Platform和Module的抽象接口定义不被改变，就可以不关心Platform和Module的实现是否改变。 这里所指抽象接口定义就是PlatformInterface和ModuleInterface，我们可以将它们放在comm_define.h中，供Platform和Module使用。 动态链接相关函数： dlopen、dlsym、dlerror、dlclose 规定动态链接的入口函数 void CreateModuleLinker (ModuleLinker * linker); 模块链接器ModuleLinker，其工作主要为： 创建module 摧毁module 取得module_id，用于唯一标识Module 先定义ModuleA，即把之前ModuleA的代码抽取出来，放在moduleA.cpp文件中。 另外还需要定义它的模块链接器ModuleLinkerA 。也放在moduleA.cpp文件中 然后用g++ -fPIC –shared –olibmoduleA.so moduleA.cpp从moduleA.cpp编出libmoduleA.so，准备给Platform用 ModuleLinker的管理，容易发现这是个创建型模式，用抽象工厂搞定它。 将之前Platform代码抽取出来，放在platform.cpp中 Platform调用Module的示