版本：0.1

最后修改：2010-12-10

撰写：李现民

引言

很多游戏都有配套的编辑器，或通用或专用，这样可以方便策划及时设计、修改游戏数据。当一个游戏方案确认实施时，如果需要设计配套编辑器，那么它往往先于游戏本身而设计。出于代码重用和方便维护的需要，大部分核心代码会在游戏客户端与编辑器中同时使用，因此有效提取这部分共用代码并尽量减少与项目其它部分的耦合就成为设计的重点。

关于良好程序架构设计的话题，比如设计模式、领域驱动设计等，相关论著恒河沙数。本文结合实践中遇到的问题，从工具与技术相结合的角度来阐述相关问题的解决方案。

以下假定程序运行环境为VC6+XP。从本文撰写时间看（2010-12-10），VC6无论如何都不是一个好的选择，但限于笔者所在公司环境如此，所以只好将就着来了╮(╯▽╰)╭。

使用宏控制代码生成策略

尽管我们追求代码的可重用性，但实际情况往往并不尽如人意，特别是在与特定于游戏客户端（或编辑器）的功能相结合比较紧密的代码部分。比如UI（界面），游戏客户端中有独立的界面模块，而编辑器界面可能使用MFC制作。即使同一个函数接口，游戏客户端与编辑器所需要的功能也可能是不一样的，这是因为它们拥有各自不同的应用倾向：游戏客户端倾向于使游戏画质更加平滑，而编辑器则需要考虑策划人员快速的编辑修改数据；再比如游戏客户端可能需要网络IO功能，而编辑器则一般不需要。

宏（具体的说，C++中的宏），此时可能是一种比较合适的工具。比如，通过在游戏客户端与编辑器中定义不同的宏变量，可以使游戏客户端专用的网络IO代码在编辑器中根本不生成。

某些情况下可能需要在同一个项目下建立多个configurations（配置），通过定义不同的宏变量以控制生成不同版本的程序，比如：简化版、完整版、内部版等。

宏在VC环境中有大量的应用案例，比如windows.h头文件中定义了大量的宏用于控制不同环境下的代码生成策略。

使用函数控制代码生成策略并信任编译器优化

宏控制的原理是将不需要的代码当作注释直接移除，因此编译器不会去审查该部分代码的正确性。这在某些情况下是必须的，比如编辑器没有网络IO相关的代码接口，因此相关代码必须被清除，否则编辑器项目将无法正确编译。

但宏控制有自己的问题：

1. 宏变量通常定义在Project Settings（工程设置）中，因此不容易记忆或查找；

2. IDE工具通常无法像支持代码一样支持此类宏变量的快速查找，特别是存在多个项目相互引用的复杂工程中（比如Visual Assist X有Find Reference功能，可以快速搜索到所有引用指定变量或函数的代码，但此功能不支持在Project Settings中定义的宏变量）；

3. 编译器无法审查被移除部分代码的正确性，这可能导致一些代码修改同步的问题。

针对这些问题，笔者的解决方案是：宏控制变量只使用一次，用于定义一个简单函数，而该函数返回当前宏控制变量的存在情况，其它原本使用宏控制变量的地方都改为使用这个函数判断。这样间接的将宏变量控制转换为函数控制，从而获得IDE工具支持与编译器代码审查的双重好处。

比如如下代码：

namespace edition
{
#ifdef _EDITOR
inline bool IsEditor() { return true; }
#else
inline bool IsEditor() { return false; }
#endif
}

void Print()
{
if (edition::IsEditor())
{
puts("This is editor");
}
else
{
puts("This is not editor");
}
}

宏变量_EDITOR只使用一次，其余地方都使用edition::IsEditor()区分是编辑器代码还是游戏客户端代码。

请注意，我们并不会有任何的运行期性能损失，虽然看起来并非如此。由于在编译期edition::IsEditor()的值是确定的，因此当打开优化时编译器会移除不可达代码，从而得到与宏控制情况下相同的可执行文件。当然，在Debug版本下（优化关闭）所有的代码都被编译生成到最终可执行文件中，但我猜您应该不会将Debug版本给最终用户使用对吧？

使用delegate解耦

在MVC架构下，使用Observer（观察者）模式将核心逻辑代码与UI界面代码分离似乎天经地义的事，这样做的好处是核心逻辑代码可以独立于UI代码而存在，从而达到重用的目的。但不幸的是，从笔者经手的代码看，很多程序员并没有注意到这一点。主要问题可能包括以下两个方面：

第一是核心逻辑代码与UI界面代码相互调用关系错综复杂。由于核心逻辑代码不独立，因而很难进行提取复用。这种情况相对比较常见。

第二个问题解释起来可能更复杂一些。由于缺乏从核心逻辑代码到UI界面代码的回调机制，程序员可能会被迫使用一些极端的手法来达到侦测指定事件是否发生的目的。比如，我们知道游戏客户端都有一个主循环main_loop，方法名称通常叫Update()或Tick()，用于更新每一帧的游戏动画。这时，程序员可能会在该循环中埋伏一些代码以侦测核心逻辑状态的变化情况，从而达到触发事件的目的。这种手法实现了功能，保持了低耦合，却降低了代码执行效率。

这两个问题的解决之道在于观察者模式。这个模式在实现上还是比较复杂的，对每一个要处理事件都需要定义对应的观察者与被观察者接口。这种代码复杂性曾使很多人望而却步（包括本人-___-），为此java中内置了java.util.Observer与java.util.Observable接口，以降低使用该模式的代价。

笔者建议的方案是使用delegate（委托）。没错，就是那个C#中的delegate，它能够极低的设计复杂度实现与观察者模式相同的解耦效果。具体实例这里不再列举，因为网上可以找到很多。如果你使用的是C#，那么你是幸运的；如果你使用的是C++，那么网上同样可以找到设计好的仿真类库；如果你不幸使用了VC6，并且实在找到出路了，那么同学你也许可以去参考一下我的另一篇文章《VC6中简易delegate实现》，或许会有点帮助。

结语

本来还想加点静态变量与通用工厂的话题的，但我发现meyers singleton在VC6中的某种应用模式下会问题（singleton对象的构造函数会被调用两次，T__T），因此先欠着账，等待下次有成熟方案的时候再说吧。不过对此问题诸位看官如果有相关宝贵经验的话不妨提携一二，感激不尽中。

版本：0.1

最后修改：2010-11-15

撰写：李现民

概述

很久以前，我写过一篇短文讨论如何在C++项目中避免使用delete的设想，基本方法是使用域（scope）对象或std::auto_ptr代替。尽管当时已经讨论在所有可能的情况，但后面在实际项目实施中发现效果并不好。原因是方面的，比如在使用std::auto_ptr时会存在以下不得因素：

1. 可能的额外开销外（其实很小）；

2. 你需要时刻小心对象所有权的问题。尽管可能只需要稍微注意一下就可以了，但似乎没有任何程序员喜欢过提心吊胆的日子；

3. 你不能在容器（比如std::vector）中存储std::auto_ptr对象；

基于以上原因，类似于Text* pText = new Text;这种直接在堆上申请内存的方式还是在代码得到了大量应用。而接下来就是如何安全、有效的回收这些内存的问题，这也正是本文所讨论的话题。

回收单个堆对象

// delete a object pointer and reset it
template<class T> void delete_null(T*& p)
{
// check if T is incomplete type, if it is, the compiler will report an error
typedef char type_must_be_complete[ sizeof(T)? 1: -1 ];
(void) sizeof(type_must_be_complete);
// delete the pointer and reset it
delete p;
p =NULL;
}

这是一个模板函数，它主要有三个作用：

第一个作用是检查被删除对象的类型完整性。这通常无法引起人们的重视，但在某些情况下可能会导致未定义行为，比如以下代码：

Text* pText = new Text;
void* pData = pText;
delete pData;

Text*类对象pText 被转换成了拥有void*对象pData，并对pData 调用了delete 删除操作。在这种情况下编译器的行为是未知的，但至少有一点：由于编译器无法推导pData 的原始类型，因此无法调用对象的析构函数。

// check if T is incomplete type, if it is, the compiler will report an error
typedef char type_must_be_complete[ sizeof(T)? 1: -1 ];
(void) sizeof(type_must_be_complete);

这两句代码可以检查被删除对象的类型完整性。其效果发生在编译期，如果对类型不完整的对象调用delete_null 删除操作，将引起编译错误。它没有运行期开销，因此使用delete_null 带来的安全性实际上免费的。

更加详细的解释可以参考boost库中的checked_delete.hpp。

delete_null 的第二个作用是回收堆对象，这没有什么可说的。

delete_null 的第三个作用是将对象指针设置为NULL，这主要是为了应对指针有效性检查，属于常规手段。

另外，注意到delete_null 被设计为一个模板函数，在发布版本（Release）中，它将以内联代码（inline）的形式存在，因此不会有运用期函数调用开销。

回收容器中的堆对象

// delete container (std::vector, std::list) items and reset them to NULL
template< typename InputIterator > void delete_null(InputIterator first, InputIterator last)
{
while(last != first)
{
delete_null(*first);
++first;
}
}

// delete functor, used for iterative delete
struct deleter
{
template< typename T > void operator()(T*& p)
{
delete_null(p);
}
};

这段代码分为两部分：一个同样叫delete_null 的模板函数与一个名为deleter的仿函数。

先来看第一部分，它同样叫delete_null，与前面介绍的那个版本所不同的是它接受一对迭代器作用输入条件，其作用是回收[first, last) 范围内所有堆对象。与std::for_each等很多STL标准算法类似，该函数可以同时应用于普通数组或存储单值的标准容器（包括std::vector, std::list, std::set等，不包含std::map）。

第二部分比较有意思：它是一个仿函数。它可以在一定程度上代替delete_null(first, last)，以下代码展示了分别使用这两种方式回收容器中的堆对象的方法：

typedef std::vector<Text*> TextPack;
TextPack uTexts1, uTexts2;
const int datasize = 100;
for (int i= 0; i< datasize; ++i)
{
uTexts1.push_back(new Text);
uTexts2.push_back(new Text);
}

// 使用delete_null
delete_null(uTexts1.begin(), uTexts1.end());
// 使用deleter
std::for_each(uTexts2.begin(), uTexts2.end(), deleter());

可以看到前者稍微简洁一些（包括最终的汇编代码），那么问题来了：为什么还需要代码量更大一些的deleter 仿函数？

理由是：并不是所有存储堆对象的集合都是直接存储对象指针的。比如可以将指针存储在std::map中“值”部分，甚至有些自定义集合只提供了遍历函数（类似于std::for_each），但并不公开迭代器接口。在这些情况下，我们就可以使用deleter 仿函数进行堆对象回收。

get与set成员函数是为代码耦合之重要原因

版本：0.1

最后修改：2009-08-21

撰写：李现民

类数据成员的访问级别通常需定义为private，以封装类的实现细节，这样可以在类的生命演化过程中提供更好实现弹性。

get/set成员函数（访问级别通常为public）使得client端用户代码可以访问对象的内部数据结构，这会暴露类内部的实现细节。这种暴露使会得用户代码与类实现之间产生深层次的依赖关系，而这种过剩的知识将在类实现技术改变时迅速破坏相关的用户代码---涟漪效果。

比如Container类输出了关于实现该类之二叉树的信息（比如，当它输出成员函数getLeftChild()与getRightChild()时），用户将被迫按照二叉树而不是容器进行思考，这将使用户代码变得复杂且难以改变。如果Container类改变了实现结构，则用户代码将被迫进行修改（可能是大量的）。

最少知识（least knowledge）原则是用于面向对象编码中降低类间耦合度的指导原则。该原则认为如果要在相互调用的类（对象）之间保持较低的耦合度，则一个对象所调用的方法应该仅仅局限于以下几个来源：

1. 类对象本身；

2. 被当作方法的参数而传递进来的对象；

3. 此方法所创建或实例化的任何对象；

4. 对象的任何组件；

一个对象可以任意调用以上四类对象的方法。唯一一类不可调用的方法来源于：通过某个对象的get成员函数所获取的间接对象的成员函数。很容易想象，当某个类拥有大量get/set成员函数时，该类本身几乎不可能提供完善的逻辑处理方法（否则也就没有必要提供这些get/set成员函数了），因此借助get成员函数获取间接对象并做进一步的处理几乎是不可避免的。

因此，在有可能的情况下，类设计人员应该尽量不提供get与set成员函数。

当然，不要认为get与set成员函数总是坏的，像CORBA这样的框架都会为所有的属性自动提供get/set成员函数。真正的问题是：好的对象总会封装并在接口后面隐藏某些东西，然而get/set成员函数有时会在暗中暴露对象的秘密。只有当在类外（从用户的角度）看待这些私有数据仍“有意义”时，为私有数据设置公有的get()和set()成员函数才是合理的。然而在许多情况下， get()/set()成员函数和公有数据一样差劲：它们仅仅隐藏了私有数据的名称，而没有隐藏私有数据本身。

注1：以上文字部分参考了《C++ FAQs》second edition, P73的内容。

注2：我们经常使用get/set成员函数作为急救带来修补蹩脚的接口。

基类角色之对象管理器

版本：0.1

最后修改：2009-07-02

撰写：李现民

问题描述

C++程序设计中，保存一个生命周期不是由类对象自己维护的其它对象的指针通常是个坏主意，因为程序逻辑很难判断在使用该指针的时刻其所指对象是否已经被销毁。这种应用需求很常见，例如在网游设计中，由于华丽的装备加载需要进行大量硬盘I/O，因此加载过程通常由一个独立的加载线程执行，由于在装备加载完成的时刻该玩家很可能已经下线，因此加载线程就需要能够去判断此时玩家对象是否仍然有效。

为了解决该问题，通常会设计一个PlayerManager类用于跟踪管理当前所有的玩家对象，而加载线程通过提供玩家id以确认该玩家对象仍然存在。此种设计方案需要一个独立的PlayerManager类，并提供一个全局的PlayerManager类对象以跟踪当前的所有玩家对象。

出于代码复用的目的，我希望实现一个通用基类解决此类问题。该基类需要为子类对象至少提供以下几方面的能力：

1. 为所有的对象分配一个全局唯一的index，通过该index能够（尽可能快的）获取到拥有该index的类对象（或NULL）；

2. 自动跟踪类对象的生成与销毁，不需要手工编写额外代码；

3. 实现迭代器，提供遍历当前所有有效对象的能力；

4. 提供“移除”接口，使得对象可以主动要求放弃被对象管理器跟踪；

5. 各子类实现拥有完全独立的管理器逻辑；

解决方案

将实现代码保存为objectman.hpp，内容如下：

测试代码

测试代码如下：

vs2008下所有断言均动作通过。

已知问题

1. 在大量生成对象的情况下，index索引空间（代码定义为int的范围）有可能使用殆尽，甚至产生重复，这会导致两个对象拥有相同index的严重错误；

2. std::map的查找速度不是特别另人满意；

版本：0.1

最后修改：2009-05-15 

撰写：李现民

依赖倒置原则（DIP）告诉我们应该优先依赖于抽象类，而避免依赖于具体类。特别是在一个正在进行开发的应用程序，有很多具体都是非常易变的，因此我们应该依赖于抽象接口，以使我们钟爱大多数变化的影响。

在典型的面向抽象的程序设计逻辑中，依赖于抽象往往意味着会衍生大量的抽象类及（更大量的）子类，从而构成一些树状的类族结构。一个必然会出现的问题是：抽象类族中子类对象由谁创建？

显然，这不应该交由客户代码处理（我们不是要依赖于抽象嘛:)）。一个典型的基于Factory Method解决方案结构如下：

该类图展现了这样的一个应用场景：类SomeApp通过接口Shape与ShapeFactory对产品类（Shape类族）进行操作。SomeApp完全没有使用Square类或者Circle类的任何特定方法。并且由于ShapeFactory的介入，SomeApp对这两个实现类的创建过程也一无所知。我知道您的疑问：“对具体类ShpeFactoryImplementation的依赖如果处理？”。答案是：工厂类对象往往由main或者由一个隶属于main的初始化函数创建出来。

使用Factory Method是有代价的：它很复杂，为了创建一个新类，就必须要创建出4个新类，这4个类是：2个表示该新类及其工厂的接口类，2个实现这些接口的具体类。尤其是在一个正在演化的设计的初期，如果缺省使用它们，就会棉套的增加扩展设计的难度。

另一个很常见的问题是：在整个项目的生命周期中，ShapeFactory很可能会自始至终保持仅有ShpeFactoryImplementation一个子类。结果是这带来了设计上的复杂性，但却在易于扩展性上得到实际的好处。

一个折衷的解决方案是使用Simple Factory，其类图结构如下所示：

注意Simple Factory虽然为很多设计模式的书所津津乐道，但其实并不是GOF的23种设计模式之一。同时，聪明的你一定已经发现现在ShapeFactory类已经不再是一个接口了。难道我们又陷入到对具体类的依赖中去了？哦，如果是的话，至少此时我们所依赖的具体类只有ShapeFactory一个，这并不会随着抽象类Shape子类的增多而增多。

新的问题是：除非ShapeFactory负责所有Shape对象的管理与维护（这时通常应该叫ShapeMan云云。注意：Man for manager，工厂类的命名中不一定要含有Factory字样的:)），否则它极容易成为一个贫血类----仅仅含有一个CreateShape()函数的类，它披着class的皮，干着function的事。

既然如此，何必要额外创建一个ShapeFactory对象（计算机说：这会降低效率的），把CreateShape() 交给Shape类不就得了？反正是她的孩子，也算天经地义（其实，不完全这样！）。新的类图呈现为下面的样子：

来看看我们的战果：

1. Factory职能由Shape类承担。通常CreateShape()可由一个static函数实现；

2. 完全消除了非必需类，这避免了创建额外新类的代价；

3. SomeApp类仅依赖一个唯一的类Shape，并且Shape是一个抽象类，这降低了客户代码与实现类之间的耦合度；

已知的代价：

1. 依赖关系环。敏感的读者一定已经发现Shape与其实现类之间形成了一种环状依赖，其代价是每添加一种新的Shape实现就必须修改CreateShape()函数的实现（能够做到不更改接口）。唯一值得庆幸的是：在Factory Method与Simple Factory的方案中，我们同样无法避免这种双向修改；

2. Shape所有权问题。尽管继承是一种比关联强得多的实体关系，但在打包时Shape最好与它的客户代码SomeApp在一起。SomeApp的实现离不开Shape，但理论上Shape却是可以脱离Shape单独存在。依赖关系环的出现会强迫Shape与它的实现类打包在一起；

3. 违反了依赖倒置原则（DIP），我们的抽象类开始依赖于具体类；

4. Shape不再是一个接口。如果说Factory Method与Simple Factory中的Shape还有可能是接口的话，那么在最后一方案中具体函数CreateShape()的加入则完全打破了这种可能。

如果：在一个项目演化的初期，您还不确信您需要创建一些Factory类；或者，您已经确信可以承受该方案的代价并且期望得到它所带来的好处的话，那么您不妨尝试一下。

参考文献

1. 《敏捷软件开发 原则、模式与实践》 P239：FACTORY模式；P279：ABSTRACT SERVER模式；