1）构造函数没有返回值，报告构造函数错误的最常见方法是抛出异常，其他方法都不靠谱，例如：

A::A(int& error)

{

    // ...

    if (错误) error = -1;

}

2）构造函数中抛出异常，所有的父类的析构函数将被调用，但是本类的析构函数不会被调用。

3）构造函数中抛出异常，分配的空间将被自动释放。

4）在构造函数里面，虚函数将没有 virtual 特性，如果直接或者间接调用了一个未实现的纯虚函数，将导致未定义行为。因此不要在构造函数中调用虚函数。

对于资源，这里我分为两类：

1. 内存资源

2. 非内存资源（文件、网络资源等）

C++ 对于内存资源的管理部分是自动的：栈上的内存资源将被自动释放，堆上的内存资源需要程序员自己释放。

手动管理内存资源，总会让我们在一些极端情况下犯错。一个最简单，最常见的例子如下：

void f()

{    

    A* a = new A();    

    B* b = new B();    

    C* c = new C();    

    // ...    

    if (某种条件)    

    {        

        // 失败时        

        delete a;        

        delete b;      

        delete c;        

        // ...        

        return;    

    }    

    // 成功继续处理    

    Z* z = new Z();    

    try    

    {        

        f2(); // f2 可能抛出异常    

    } catch (const xxx&) {        

        delete a;        

        delete b;        

        delete c;        

        // 忘记释放 z    

    }    

    // 没有异常继续处理

}

不论是多么优秀的程序员，他也不能保证永远正确的释放了内存资源，遇见上面情况的解决办法之一就是使用 autoptr，我们可以这样写：

void f()

{    

    autoptr<A> a(new A());    

    autoptr<B> b(new B());    

    autoptr<C> c(new C());    

    // ...

    if (某种条件)    

    {        

        // 失败时，无需释放资源        

        return;    

    }    

    // 成功继续处理    

    autoptr<Z> z(new Z());

    try    

    {        

        f2(); // f2 可能抛出异常    

    } catch (const xxx&) {        

        // 无需释放资源    

    }    

    // 没有异常继续处理

}

不错，这看起来很完美，我们解决了异常情况下内存资源释放的问题。但是，对于非内存资源呢？例如：

void f()

{    

    FILE* pf1 = fopen("killercat.blog1", "w");

    FILE* pf2 = fopen("killercat.blog2", "w");

    FILE* pf3 = fopen("killercat.blog3", "w");

    // ...    

    try

    {        

        f2(); // f2 可能抛出异常    

    } catch (const xxx&) {        

        fclose(pf1); // 又回到了丑陋的代码

        fclose(pf2);

        fclose(pf3);    

    }

}

很显然，FILE 不是一个类，我们无法使用诸如 autoptr 这样的管理器来进行资源的生命周期管理，对非内存资源的生命周期的管理，我们有另外一种方式可循：把非内存资源的生命周期的管理转化为内存资源的生命周期的管理。

RAII（Resource Acquisition Is Initialization），资源（这里的资源通常是指的是非内存资源）获取即使初始化，换而言之，我们将利用 C++ 构造函数和析构函数来维护一个不变式（invariant）：对象存在则资源（常常指非内存资源也可以只内存资源）有效。一个经典的例子就是：

// use an object to represent a resource ("resource acquisition is initialization")

class File_handle

{

    // belongs in some support library

    FILE* p;

public:

    File_handle(const char* pp, const char* r)

    {

        p = fopen(pp,r);

        if (p==0)

            throw Cannot_open(pp);

    }

    File_handle(const string& s, const char* r)

    {

        p = fopen(s.c_str(),r);

        if (p==0)

            throw Cannot_open(pp);

    }

    ~File_handle()

    {

        fclose(p);

    } // destructor

    // copy operations and access functions

};

void f(string s)

{

    File_handle file(s, "r");

    // use file

}

从上面的 File_handle 类可以看出，构造对象的时候，我们初始化非内存资源 FILE，当对象释放时，FILE 同时被释放。

通过 RAII 我们能够将非内存资源生命周期管理转换到内存资源生命周期的管理上来，那么上面丑陋的代码转化为：

void f()

{    

    autoptr<File_handle> pf1(new File_handle("killercat.blog1", "w"));

    autoptr<File_handle> pf2(new File_handle("killercat.blog2", "w"));

    autoptr<File_handle> pf3(new File_handle("killercat.blog3", "w"));

    // ...    

    try    

    {        

        f2(); // f2 可能抛出异常    

    } catch (const xxx&) {        

        // 资源能够被正确释放    

    }

}

RAII 的实质：

1. 通过把非内存资源的生命周期管理转化为内存资源的生命周期管理，达到对非内存资源的安全释放。

2. 通过维护一个 invariant（对象存在即资源有效），来简化编程。

当然，这里不仅仅可以使用 autoptr 也可以使用 shared_ptr 等智能指针。不过，除此之外，RAII 还维护了一个 invariant --- 对象存在即资源有效，invariant 的出现，必定带来一个结果：简化编程。看下面的例子：

class File_handle

{

    FILE* p;

public:

    File_handle(const char* pp, const char* r)

    {

        p = fopen(pp,r);

        if (p==0)

            throw Cannot_open(pp);

    }

    File_handle(const string& s, const char* r)

    {

        p = fopen(s.c_str(),r);

        if (p==0)

            throw Cannot_open(pp);

    }

    ~File_handle()

    {

        fclose(p);

    } // destructor

    int GetChar()

    {

        // 无需检查 p，因为 p 一定有效

        return fgetc(p);

    }

};

我们可以看到，在对象存在的时候，文件资源总是有效的，因为我们无需判断指针 p 是否合法，这简化了编程，使得代码更加优雅。相比之下，这样实现就不那么美观：

class File_handle

{

    FILE* p;

public:

    File_handle()

    {

        // 必须初始化为 NULL，否则下面的所有检查将无效，代码将非常脆弱

        p = NULL;

    }

    ~File_handle() {}

    void Open(const char* pp, const char* r)

    {

        // 必须判断，是否调用两次 Open

        if (p == NULL)

        {

            p = fopen(pp,r); 

            if (p==0) 

                throw Cannot_open(pp);

        }

        else

        {

            throw Close_first();

        }

    }

    void Close()

    {

        if (p != NULL)

        {

            fclose(p);

            // 必须置空，否则程序其他地方判断将失效

            p == NULL;

        }

        else

        {

            throw Open_first();

        }

    }

    int GetChar()

    {

        // 类似于 GetChar 的函数都需要判断，否则在调用 Open 之前调用程序将出错

        if (p != NULL)

        {

            return fgetc(p);

        }

        else

        {

            throw Open_first();

        }

    }

};

显而易见，对于资源是否有效的判断已经使得程序员是否疲惫，而且，他们还需要不停的维护资源的指针，只要任何一步出错，程序都将变得脆弱，更作用的是，不但编写这样的程序不会有任何快感，使用这样的代码也十分郁闷，比如调用 GetChar 的时候，需要当心函数抛出的来异常，不断的写 try catch（如果使用 error codes 来表示错误，也需要不断的判断函数执行是否出错），在一些复杂的情况下，更加让人抓狂：

bool AddGroup(int idUser)

{

    // 检查 idUser 是否允许加入组

    // ...

    // 检查成功，允许加入，扣去入会费

    SpendUserMoney(idUser, 10000);

    // 对于入会成功用户增加一个等级

    AddUserLevel(idUser); 

    // 等等操作

    // 将其写入文件中

    try

    {

        // 在文件中写入用户当前等级，入会花费等信息

        file.Write("xxx");

    } catch (const Open_first&)

    {

        // 异常出现

        // 恢复现场

        AwardUserMoney(10000);

        ReduceUserLevel(idUser);

        // 等等

    }

}

由上例可见，为了处理异常情况而做的工作太大，而且我们每次调用时都要进行相似的处理。虽然上例不一定完全合乎实际情况，或许你认为它还有改良的空间，不过无论如何，我们难免要做太多多余的工作。

自此，已经谈完了 RAII 设计方式的好处，那么下面谈谈应该注意一些什么：

1. 如果没有必要，应该禁止复制。

如果没有必要应该禁用复制构造函数和赋值操作符，这点很重要，如果没有按需要定义复制构造函数和赋值操作符，那么得到的结果通常是：非内存资源被创建一次，释放多次。

2. 如果需要复制，应该谨慎考虑。

重新定义复制构造函数和赋值操作符是必须的。怎么写它们是一个问题，具体的方案依赖于实际的需要，可以使用深拷贝，也可以使用类似于 shared_ptr 的引用计数机制，或者传递所有权。

总结一下：

1. 使用 RAII 能够将非内存资源的生命周期管理转为内存资源生命周期的管理，使得我们能够使用管理内存资源的手段来管理非内存资源，例如 auto_ptr，shared_ptr。

2. 维护 invariant 能够简化编程，使的代码简洁优雅。RAII 设计方式维护了这么一条 invariant：对象存在则资源有效。除此之外，我们还可以使用异常机制来维护另外一条 invariant：函数要么执行成功得到正确的结果，要么抛出异常。对此条，这里就不做任何阐述了。

3. 使用 RAII 时，应该警惕复制行为。

int f(); // 如果返回 0 表示错误，正常的返回值大于 0

上面这个函数很显然把函数的结果和错误信息混合在一起了，那么如果我们出现这样的函数：

int Div(const int num1, const int num2); // 两个数相除

如果 num2 为 0 那么必定引起错误，这个时候，应该用什么值来表示错误？用 0 吗？显然 0 属于合理的输出区间，不能用来表示错误。其实，我们没有办法用任何数字来表示这个错误。作为改进，可以使用这样的办法：

bool Div(const int num1, const int num2, int& res); // 使用输出参数 res

显然，我们把函数结果和错误信息分开了。看下面一个函数：

bool Save(const Data& data, int& index); // 这个函数用来保存数据 data 到磁盘中并且返回一个在磁盘中索引文件的 index，这个 intdex 可以为任何整数。

这里，我们使用了 bool 表示操作的是否成功。然而情况可能比较复杂，失败可能由多种情况引起，我们需要知道是什么原因，以便进行相应的处理。所以，我们改造一下：

int Save(const Data& data, int& index); // int 表示错误的类型

在对软件可靠性要求非常高的程序中，我们会关注每一个可能发生的错误，比如 new 失败等。我们不能去忽视那些应该面对的异常现象。因此，这里首先需要做一个约定：每个函数都应该分离错误信息和函数的输出。这个约定应该是高可靠性软件开发中必须要遵循的约定，否则开发者可能按照习惯编写出 int Div(const int num1, const int num2) 之类的函数，对于那种自己觉得很难发生的异常现象，从心理上拒绝或者偷懒，如果真的出现有人这样调用 Div(10, 0) 那么他大概会开始埋怨调用者的无知了，而不是自己的函数无法包容错误的输入。

那么，我们现在有多种选择，第一个，就是用 int 作为每一个函数的返回值，然后用输出参数来处理函数的输出。例如：

int Div(const int num1, const int num2, int& out);

要么提供 GetLastError 和 SetLastError 的函数：

int g_error;

int GetLastError() { return g_error; }

void SetLastError(const int error) { g_error = error; }

来管理错误。实现 Div：

int Div(const int num1, const int num2)

{

   if (num2 == 0)

   {

        SetLastError(1); // 1 表示除 0 的异常

        return 0;

    }

    SetLastError(0); // 表示成功

    return num1 / num2;

}

此外也许还有很多方式，但是在 C++ 中一种更好的方式是使用异常。

使用异常处理异常情况可以做出一个保证，如果函数能够输出值，那么它一定输出一个正确的值，否则就是异常情况出现了。

异常是语言内建的一种机制。如果我们使用返回值来标识错误：

int f1()

{

    if (x)

        return EXC_1; // 异常情况 1

    if (y)

        return EXC_2; // 异常情况 2

}

int f2()

{

    int exc = f1(); // 调用 f1

    if (exc == EXC_1) // f2 函数对于 f1 的失败很无奈，它无法处理只能告诉上层

        return EXC_1;

    if (exc == EXC_2)

        return EXC_2;

    if (z) // 自己可能发生的问题

        return EXC_3;

}

我们可以想象，有时候对于这种处理是很痛苦的，但是又不得不这么处理。特别是：

bool IsGood()

{

    // ... 一些操作

}

现在需要变化，导致我们需要改变 IsGood 的实现，IsGood 需要调用到 f2，那么：

bool IsGood()

{

    int exc = f2();

    exc ... // 怎么告诉上层出现了什么错误？返回值为 bool

}

除非我们去改变 IsGood 函数的原型，否则上层将无法得到任何异常的信息（在需要的时候），而改变接口的代价是巨大的。

换过来想想异常处理，一切问题都不存在。我们能够借助异常机制，编写极其健壮的代码，编写出只要操作系统不崩溃，那么就不会崩溃的程序。很多书籍指出异常将导致整个系统复杂度增加，这是毋庸置疑的，但是要明白的是，程序中本来就存在很多隐患，只是这些隐患只在极端的情况下发生，于是乎大多数人把它忽略掉，以求得一个“简单”的系统，事实上，无论使不使用异常机制，异常现象都是存在的。当你要让你的程序包容任何异常问题时，使用异常机制绝对是一个好的选择。

子程序的最大的两个用途：

1）隐藏信息

2）避免重复代码

1. 隐藏信息

隐藏信息是子程序的一种功能，但是只有命名合理的子程序才具有此项功能，命名合理即：子程序以及参数的名称能够反映出子程序的含义。

子程序能够隐藏信息，特别用于隐藏以下几种信息：

<1> 复杂的嵌套信息

如果出现复杂的 for 或者 if 嵌套而又不可避免，那么可以把深层的嵌套放入一个子程序中来完成，例如：

for (int i=0; i<MAX; ++i)

{

    if (xxx)

    {

        if (yyy)

        {

            zzz;

        }

    }

}

这个时候，if 语句可以放入一个命名合理的子程序中，这样对于阅读者或者开发者来说程序更加容易理解或编写。这时，子程序的名字和参数是对子程序含义的一个说明，因此，如果你编写子程序的目的在于隐藏信息，那么你就必须提供足够的能够清楚反映子程序功能的名称。

<2> 顺序信息

执行某些操作需要按一定顺序进行，我们可以通过一个子程序来隐藏这种顺序：

IDevice* device = createDevice();

device->Init(); // 必须最先调用

device->CreateXXX(); // 必须在调用 Init 之后调用

device->CreateYYY(); // 必须在调用 CreateXXX 之后调用

那么，我们可以把上面的操作放入一个子程序中，让子程序来隐藏调用的顺序信息。

2. 避免重复代码

“重复”一词在程序设计中总是不太好的东西，重复计算带来额外的消耗，例如：

int f(int n)

{

    if (n == 1 || n == 0) return 1;

    else

        return f(n - 1) * f(n - 2);

}

这是一个典型的低效的递归函数，很明显，我们计算 f(n - 1) * f(n - 2) 的时候，在计算 f(n - 1) 时需要计算一次 f(n - 2)，后面 * f(n - 2) 时，又计算了一次 f(n - 2) 这种重复计算是导致效率低下的根本。

同样，重复的数据出现，导致数据同步的麻烦：

class User

{

    string name; // 玩家名字

}

class Flower

{

    string userName; // 送花的玩家的名字

}

我们在一个送花系统中保存了送花玩家的名字，如果玩家改名了，那么我们需要同时改变送花系统中记录的玩家的名字，这显然是麻烦的。

当然，现在要讲到的重复，不是计算重复，也不是数据重复，而是代码重复。代码重复和数据重复一样，代码的后果是 --- 惧怕变化。例如：

void f1() { XXX; A; YYY; } // A 表示一段代码

void f2() { A; ZZZ; } //  A 同于上面表示的代码

那么，如果系统由于某些原因需要改变，导致 A 发生变化，那么变化将影响到 f1, f2 两个函数。

另外，重复代码带来阅读上的不方便，特别是程序中含有大量相似代码时，阅读很困难，这时候，应该提取相似代码的共性，放入一个子程序中。

误区：不要认为子程序的只是用来避免重复代码的，换而言之，有一些程序员可能认为，只有 1，2 行并且也只在一个地方出现的代码不应该做成一个子程序。这种观点是不正确的，子程序有时候充当一种注释的角色：

int GetID() { return m_id % 1000; } // m_id 的后 3 位表示 id 号

在程序中使用 GetID 来代替 m_id % 1000 将更加好读。

内聚性，子程序中各个操作之间的关联的紧密程度，如果子程序中各个操作关联非常紧密，那么我们称之为高内聚，相反位低内聚。pow 这样的函数是高内聚的，而诸如 SetAttr(int value, bool synchro); 这样的函数内聚性就稍低。

为什么一个子程序只做一件事是好的（KISS）？

只做一件事情的子程序是高内聚的。这种程序不容易出错（据调查研究得知），另外这样的程序很好命名，那么从子程序的外层（调用者一层）和子程序的内层（子程序内部）来看，可读性都是高的。

参数问题：

子程序的参数可能只是用来使用，而不会被修改的参数，这被叫做输入参数；

如果参数只是用于返回值出去，而子程序不使用它的值，这种参数叫做输出参数；

如果参数的值将被子程序使用并且会修改它，这种参数叫做修改参数。

我们可以规定一个参数的排列顺序：输入 --- 修改 --- 输出。这种统一的风格，可以使得代码更加可读。

在 C++ 中，我们可以使用关键字 const 来标明参数为输入参数，使用引用类型（或者指针）来表明参数是一个修改或者输出参数（你甚至可以规定，修改参数使用指针类型，输出参数使用引用类型），例如：

bool Add(const int num1, const int num2, int& res); // num1 和 num2 为输入参数，res 为输出参数

Windows 下做 C++ 开发的程序员很喜欢使用 IN OUT，例如：

bool Add(IN int num1, IN int num2, OUT int& res); // 同上

IN，OUT 的缺点在于，它不是语言的一部分，那么如果有这么一个函数：

void f(IN User& user); // user 是一个输入参数

在某些情况下，需求变化了，某个代码的维护人员修改了 f 函数的实现，使得 user 变成了一个修改参数，而 IN 没有被改为 IN OUT，这样必定给代码阅读着带来疑惑，而且编译器也不会去警告开发者。

很多人不愿意使用 const 去修饰输入参数，他们觉得这是多余的，但是我们看下面的程序：

int f(int num)

{

    // .... 很多操作，num 被到处使用，这时候你无法确保 num 会不会被修改

}

如果这个函数比较长（我见过 2000 多行的），里面的逻辑比较复杂，你在维护代码时，也许你需要最初传入的 num 的值，但是你又很难确保 num 没有被修改。

关于函数返回值的一个议题：

我们应该使用 ---

int Add(const int num1, const int num2);

还是 ---

bool Add(const int num1, const int num2, int& res);

这是一个值得考虑的问题，尤其是在软件可靠性变得异常重要的时候，在一些极端的环境中，完全正常的程序可能就失效了。

为此，我做了仔细的思考，并且把有关的问题陈述于此：http://www.i170.com/user/killercat/Article_115829

另外，这里还有一篇可以参考的文章：http://wesleybao.spaces.live.com/Blog/cns!1p0i3yoUKRgnWt0UyAV1FMog!935.entry 

1、阅读代码应该以 Routine 为单位。在阅读某个 Routine 时，应该理解其实现，当在其他地方调用此 Routine 时，你无需回忆此 Routine 的实现细节（甚至应该忘记具体细节），但是你必须知道此 Routine 的含义，详细来说，包括 Routine 的参数和返回值以及 Routine 本身的含义。你的每个接触的 Routine 及其参数的含义的熟练程度，直接影响到你阅读代码的速度。

低质量代码标志：Routine 的名称无法反映其含义，参数名称无法反映参数含义，出现多个名称类似的无法区分含义 Routine，例如：

bool IsTypeValid(int typeID); // 用于检查数据库中是否存在此 typeID

bool CheckType(int typeID); // 用于检查 typeID 是否处于合理的区间

我们很难从名字上区分两个函数的含义。

好的命名是：即使我们忘记了 Routine 的实现，但是我们也能通过名字很明确的知道 Routine（以及参数）的含义。

2、如果出现共享数据，那么就需要去理解它的含义。

低质量代码标志：共享数据泛滥，你很难确定某个数据到底什么时候被赋值，代码难以阅读和维护。

3、总结代码中的惯用法。代码中，总会留有作者的编写代码的一些习惯，总结这些编写习惯，能够提高理解代码的速度。例如：

笔者见过的一个作者非常喜欢使用的一种手法，这里先不讨论这种做法是否合理：

int g_id;

void SetID(int id)

{

    g_id &= 0xFF00;

    g_id |= (id & 0x00FF);

}

void SetIDType(int type)

{

    g_id &= 0x00FF;

    g_id |= (type & 0x00FF);

}

上面的代码，没什么经验的程序员初次见到一定是一头雾水，它实际上把一个 int 变量分成了 2 部分，一部分用来保存 id 的值，一部分用来保存 id 类型的值。其目的之一在于节约内存。很明显，如果读者不知道作者的惯用法，不去总结作者的惯用法，那么在读代码时非常容易一头雾水，越读越糊涂。

低质量代码标志：读者通常最无法忍受的是没有统一风格的代码，同种设计思想使用不同的写法，不同的命名风格，没有章法的参数排列等等。

4、读代码只能精读。代码不如小说，即使一目十行也能看个梗概。代码不如文字，即使再怎么显而易见，也需要读者一行一行仔细看下去。

1. 错误根源

链接时，链接器需要寻找程序所引用的标识符，如果在所有的库文件（.lib）和目标文件（.obj）中找不到就会产生链接错误。

2. 引起错误的常见原因：

1）工程内函数只声明而没有定义：

C++ 允许函数声明而不用定义，例如：

int Add(int, int); // Add 没有定义

int main()

{}

但是如果我们需要调用 Add 函数，即：

int main()

{

    Add(1, 1); // 找不到标识符，链接错误

}

最常见的情况是，类成员函数只声明而没有定义。更为微妙的情形是：

我们有一个接口：

class IUser

{

public:

    virtual int GetID() const = 0;

    virtual void SetID(const int id); // 这里不小心漏掉了 = 0

};

class User : public IUser // 实现类

{

protected:

    virtual int GetID() const;

    virtual void SetID(const int id);

};

// User 的实现略

int main()

{

    // ...

    IUser* user = GetUser(id);

    user->SetID(1); // 注意这里

}

 不多说，先看几张图：

flash demo:

The aim of the C++ class concept is to provide the programmer with a tool for creating new types
that can be used as conveniently as the built-in types.
A type is a concrete representation of a concept.

一个类型是一个概念的具体表述。这不意味着一个概念需要用一个类才能表示。

实际上，我们通常还可以使用别的手段来描述一个概念，比如说，我们使用两个变量 x, y 来表示点的概念。

但是，不得不承认的是，类通常是一种友好的用于表述某个概念的工具。现在看一个例子：

class Car

{

public:

    void Run(int x, int y); // 这是一部在陆地上行走的车

};

注意，我们使用了两个变量来表示“点”的概念。

忽然有一天，我们的所有的车能够在天上飞了，不存在那么只能走在陆地上的车了，结果导致程序员不得不去修改接口：

class Car

{

public:

    void Run(int x, int y, int z); // 从 2D 转向了 3D

};

可以想象，这接口的改动带来了不少的麻烦。假如当初我们使用类来表示“点”的概念：

class Car

{

public:

    void Run(Pos target); // Pos 是一个表示点的概念的类

};

那么，如果车能飞上天，那么仅仅需要修改 Pos 类的实现（如果接口设计好的话），而不是 Car 类的接口了。程序员的负担相对较低了。

这里，我想表达的是这么一个观点：尽量用类来表达一个概念。

设计者应该真正理解偶然复杂度，如果设计出来的框架，在进行开发时需要开发人员关注于系统的每个细节，那么对于程序员来说偶然复杂度是高的，相比下，对于每个功能的开发，程序员只需要关心当前编写的任务，那么偶然复杂度是低的（COM 的设计非常强调的一点是封装，而不是复用）。

设计的基本的原则：

1）尽量降低偶然复杂度。如果可以简单的解决问题，那为什么不这么做了？另外某些角度来说：

模块化的系统（系统对“模块”一词有确切的定义），在一定程度上偶然复杂度较低，模块化的系统让程序员只需要关心当前开发的部分。

2）尽量保持高内聚，低耦合。高耦合的系统惧怕变动（动一处而牵动全身），变动带来的问题通过关联进行传递。高耦合的系统的关键点在于：系统组成部分的关联过多，导致过多的相互影响，当关联数量到一定程度，整个系统就会很不稳定。

具体来说：

<1> 集成的困难：高耦合的各个程序组成部分需要花费较多时间进行集成。

<2> 测试的困难：一个部分的问题通过与其他部分关联传递到其他部分，那么意味着一个部分的变动可能导致整个系统的重新测试。

低耦合：在类这个层次上来说，除了底层的工具类（例如 STL）之外（工具类允许和系统中的大部分类发生关联），应该尽可能的减少类之间的关联。

3）可扩展。可扩展的一个标志是，无需改变系统底层，即可增加新的功能。

4）可移植性。可移植性非常特别（似乎违背低偶然复杂度原则），它不同于软件的其他的特性，除非你保证你的项目永远无需移植到其他的环境中去，否则，你应该注意这点，因为通常来说，时间越长，越难移植，甚至最后只能重写，代价非常之高。

5）分层。分层的系统相对来说偶然复杂度较低，关联较少。每层都有每层的工作，相互影响较小。

另外，类的粒度也比较重要，大粒度的类间关联少，但是不可避免的就是类自身过于复杂。小粒度的类自身很简单，易于开发和维护，但是类间关联变多，通讯太频繁。粒度过大和过小都会带来较多的问题，应该根据经验作合理设计。

在 C++ 中使用巨大的类无异于使用 C 语言进行编程，这意味着你抛弃了 C++ 强大的抽象能力。含有巨类的系统中的一个显著的标志是：含有大量重复代码或者相似代码（这归结于 C 语言不够强大的抽象能力和项目在时间上的压力）

最后要说的一句是：KISS 和敏捷给太多人以误解，请仔细斟酌它们的含义（有几个人懂得 KISS 的真正含义）。设计是不可避免的，好的设计是至关重要的。好的设计在一定程度上控制了软件的成本，即使你的老板并不明白，但是你应该这么做。

author: killercat

http://www.i170.com/killercat

// Singleton 模板

template <typename T>
class Singleton
{
public:
    Singleton()
    {
        assert(!ms_singleton);
        ms_singleton = static_cast<T*>(this);
    }
    ~Singleton()
    {
        assert(ms_singleton);
        ms_singleton = 0;
    }
    static T& GetSingleton()
    {
        assert(ms_singleton);
        return *ms_singleton;
    }
    static T* GetSingletonPtr()
    {
        return ms_singleton;
    }
protected:
    static T* ms_singleton;
};

// 使用模板（省略了原有的大量代码）

class _OgreExport LogManager : public Singleton<LogManager>, public LogAlloc
{
public:

    LogManager();
    ~LogManager();
    static LogManager* GetSingletonPtr(void);

    static LogManager& GetSingleton(void);
};

OGRE 中使用引擎本身去调用构造函数的方式初始化 Singleton，而我们常见的 Singleton 都是第一次调用 GetSingleton 来创建实例，另外 Singleton 本身也不负责释放 ms_singleton。实际上，OGRE 的 Singleton 把对象生命周期的管理分离了出去，那么只要外部管理对象生命周期正常，那么使用 Singleton 永远不会出现问题，这样的设计使得 Singleton 更加容易使用在多线程的环境中，读者可以阅读 ACE 中 Singleton 的实现方式（n 种实现）。OGRE 的 Singleton 只是通过 Assert 通知用户已经存在实例，而没有禁止用户产生多个实例。

笔者对 OGRE 的 Singleton 稍微修改了一下：

#define SINGLETON_DECLARE(T) static T& GetSingleton(); static T* GetSingletonPtr();
#define SINGLETON_IMPLEMENT(T) template<> T* Singleton<T>::ms_singleton = 0;\
    T* T::GetSingletonPtr() { assert(ms_singleton); return ms_singleton; } \
    T& T::GetSingleton() { assert(ms_singleton); return *ms_singleton; }

template <typename T>
class Singleton
{
protected:
    Singleton()
    {
        assert(!ms_singleton);
        ms_singleton = static_cast<T*>(this);
    }
    ~Singleton()
    {
        assert(ms_singleton);
        ms_singleton = 0;
    }
protected:
    static T* ms_singleton;

    // Hide
private:
    Singleton(const Singleton&);
    void operator=(const Singleton&);
};

// 使用代码

class MyMgr : public Singleton<MyMgr>
{
public:
    SINGLETON_DECLARE(MyMgr)
    void SayHello();
};

SINGLETON_IMPLEMENT(MyMgr)

void MyMgr::SayHello()
{
    cout << "Hello world!" << endl;
}

命名必须要注意的两点：

1）永远不要使用晦涩的名字

2）总是使用全大写字母表示宏和常量

匈牙利命名法：

匈牙利命名法的一个特点是将类型信息混入名称中，例如：

int nNum = 0; // n 为类型信息，表明 nNum 是一个 int 类型

class CUser; // C 为类型信息，表明 CUser 是一个类

通常的观点认为，在名称中加入类型信息会增加代码的可读性，实际上，这种效果甚微。加入类型信息的不良表现之一是降低可维护性，一个很简单的例子：

class CUser

{

private:

    int m_nID;

}

如果出现某种情况导致需要修改 m_nID 的类型为 long，那么 m_nID 应该改名字为 m_lID，那么意味着要在整个类中修改 m_nID。更糟糕的情况是：

class CHome

{

public:

    void f();

}

void CHome::f()

{

    int nID = m_pUser->GetID(); // nID 需要改成 lID

   // 下面大量使用 nID

}

可见，CHome 中的 f 函数的局部变量 nID 在 id 类型由 int 变成 long 时也受到了影响。

总的来说是将类型信息引入名称中致使维护成本增加，我们本无需因为类型的改变维护名称，匈牙利命名法将类型绑定在名称上，使得必须在类型变动时维护名称。

在泛型编程中，几乎无法使用匈牙利命名法，因为具体的类型信息并不存在。

除非你使用纯文本编辑器，否则名称中加入类型信息的做法不会为你增加任何可读性（现代的 IDE 甚至是一些高级文本编辑器，在你用鼠标点击到变量名称上时，就能显示变量的类型），它已经过时了。

一套可行的命名规范：

1）类名、枚举名、结构名、联合名、typedef 定义的类型名、函数名可以使用 LikeThis 的命名方式。

2）变量名使用诸如 likeThis 的命名方式（首字母小写）

3）类成员变量名前加 m_ 例如：

class User

{

    int m_id;

}

全局变量前加 g_ 例如：

int g_id;

静态变量使用 s_ 例如：

static int s_id;

这里说明一下，为什么需要把作用域和链接性信息融入名称中：

<1>变量作用域和链接性改变的情况是很少的，例如，很少的情况下会把一个成员变量改成静态变量

<2>编程中使用的工具常常不会直观的显示变量的作用域和链接性

<3>在许多高质量的代码中，均不同程度的将作用域信息融入变量名称中（通常使用 "_" 来表明其作用域）

对于静态类成员变量，通常使用如下方式表示：

template <typename T>

class Singleton

{

protected:

    static T* ms_instance; // 作用域前于链接性

}

4）宏和常量使用 LIKE_THIS 的命名方式

5）namespace 使用小写字母命名

6）接口使用 ILikeThis 的命名方式