模板方法（Template Method）的意图正是『定义一个操作中的算法的框架，而将一些步骤延迟到子类中』。

注意，这里有个关键词『一些』，既然是『一些』，就意味着父类的的接口中已经实现了『一些』步骤，否则，父类便只提供了抽象接口。

这一情况是我们在编码时时常遇到的，父类实现了部分算法中的通用行为，子类根据自己的需求可对其进行必要扩充。

class CBase
{
public:
    // Default done
    virtual void Operation(void)
    {
        ...
    }
};

class CDerive :
    public CBase
{
public:
    virtual void Operation(void)
    {
        switch( ... )
        {
        case A: ...
        case B: ...
        case c: ...
        default:
            CBase::Operation();
        }
    }
};

因为对父类的不了解或是对子类的太了解，你以为CDerive::Operation()做了足够多，不需要CBase::Operation()，但实际上仍然需要的情况总在发生。

换一种方式，把Operation()作为模板方法，把DoOperation()作为可扩展的接口提供给子类实现：

class CBase
{
public:
    void SetFocus(void) { ... }
    void ResetFocus(void) { ... }
    // Call by user
    void Operation(void)
    {
        SetFocus();
        DoOperation();
        ResetFocus();
    }
    // Default done
    virtual void DoOperation(void) = 0;
};

class CDerive :
    public CBase
{
public:
    virtual void DoOperation(void)
    {
        ...
    }
};

模板方法只是提供了一个简单的封装技巧，当然不是所有的虚接口都这么写:)。

更多内容请移步我的个人主页。

试过以下一些方法：

1、无效断点所在的项目和启动项目的设置：项目->属性->配置属性->C/C++->常规->调试信息格式，这里不能为『禁用』；

2、项目->属性->配置属性->链接器->调试->生成调试信息，这里设为『是』；

3、C/C++->优化->优化选择『禁用』；

4、删除解决方案下的.ncb文件；

5、工具->选项->调试->『要求源文件与原始版本完成匹配』去掉勾；

6、最后在上述设置的情况下，重新编译整个解决方案；

7、回过头来，发现原来是一段不会被执行到的代码……

一般的RPG游戏中，玩家角色、NPC、物品、场景等一般都具有为数众多的各种属性，使用C++编码时，很容易考虑设计成为大量的成员变量和相应的存取函数：

乍一看，非常清晰明了。在一个稍显复杂的项目中，想记住、甚至找到每一个属性是非常难的，况且除了属性，还有大量的逻辑处理，甚至是不同项目间的数据交互，比如将属性的数据库存取。这么做的缺点大致有这么几点：

1. 属性没有明确分门别类，尤其在多人协作、多模块编写时，往往上面一批、下面一批，甚至有重复属性、废弃属性，难于管理和把握；

2. 对于数据库存取，需要写单独的存取接口，而且一旦属性有增减、修改，存取接口要随之修改；

3. 通过接口函数进行简单的属性存取面临大量的堆栈保存，即使使用内联或宏定义，也是治标不治本。

针对上述问题，我的思路也比较简单：对基本类型数据进行二次封装。

private:
    tagDBAttrs    m_DBAttrs;
    string        m_strA;
    CObject*      m_pObjB;
    CShape*       m_pShapeC;
    ...
}; 

之所以提到基本类型数据，主要缘于基本类型构成的结构可以通过sizeof运算符直接确定，而像类对象等组合类型，其深拷贝、赋值、操作及赋值等逻辑则较为复杂，一般无法统一处理。

以上面的tagDBAttrs为例，对于基本类型数据处理具有非常大的优势，尤其在数据整体存取时，此外，增减基本类型属性也比较简单，而且不需要重写Get/Set接口，同时方便了对属性的分门别类处理。

此处顺便谈谈关于开发中的一些杂的体会。

对于工作不久的同学而言，拿到一个任务有可能出现以下两种情况：

1. 以快速开发为重，前期进展较快，在小型模块开发中顺风顺水，但在面对复杂任务时，因为对前期设计重视不足，后期会不断调整代码，甚至在基本功能开发结束后，因为逻辑架构问题，导致bug隐患较多较深，容易陷入泥沼，痛苦挣扎；

2. 随时随处追求代码结构的优美和执行效率的优化，精益求精，往往在前期设计上花费过多的心思，以达到较合理的逻辑结构，甚至拖延整个项目的开发进度，这种同学一般说来，代码质量较高，后期bug较少。

其实，上面说的就是我自己，我刚开始工作的时候，上面给我一个编写独立工具的任务，当时急于表现，缺乏项目实战经验，为编码而编码，逻辑结构不注重扩展性，设计不合理，在进行到后期时，面对出现的新需求无法应对，导致最后推到重来。

后来，慢慢接受了注重前期设计的观念，更因为自己的完美情结和代码洁癖，不仅经常调整自己编码中不优美的片段，甚至越俎代庖去修改其他同事的代码，追求处处的高效，耗费大量时间精力，难以自拔。

在任何一个项目中，都有轻重主次之分，也就是所谓的『8020原则』，关于『8020原则』怎么理解都行，我的理解就是，每个项目中的效率瓶颈是20%的核心代码，80%的时间和工作重心应该放到这20%的核心代码上。放到一个小的模块中也是这样，应该确定工作重心，在开发进度的限制下，对核心代码精益求精，对非效率瓶颈可以适当减少侧重。

对于新人，最难的就是从整体的高度确定20%的工作重心，这主要依赖于自身素质的提高和开发经验的积累。而对需求深入细致的分析和对逻辑精益求精的设计本身可以训练一个人分析问题、解决问题的能力。

总结一下的话，也正是我们项目组历来所倡导和坚持的：

1. 精益求精；

State模式适用较广，这儿给出比较常见易懂的三种情况：

1. 当怪物在面对不同职业和特性的玩家时对应不同的AI处理和技能释放：

或者使用分支结构：

阅读全文

之所以要写Google，Google是我的梦，正像我当初在一份简历中写道的：

Game is my interest, so I like developing my game; Google is my life, so I love enjoying my life.

我的工作、学习、生活离不开Google：My indispensable tools: Gmail, G.cn, Code, iGoogle, Picasa, Reader, Talk, Notebook, Map, Calendar, Documents, Google Pinyin, Chrome, etc.

不煽情了，坊间流传的最多的就是富有传奇色彩的Google的工作环境和待遇，下图可以说明很多问题了：

阅读全文……

之前曾经三次写过Fibonacci数：2007年4月的我的Fibonacci数列，2007年12月的也说说级数求和(1+2+3…N)和其他，2008年5月的动态规划算法，但给出的都不是非常优的算法。

上次回去把同学借的《编程之美》偷过来还没怎么看，晚上翻了一下，看到有讲Fibonacci数，想起来Knuth的The Art of Computer Programming Vol.1也讲过，觉得有必要对Fibonacci数做个了断。

诚如Knuth在The Art of Computer Programming Vol.1所述，Fibonacci是中世纪以来欧洲最伟大的数学家，他关于al-Khwarizmi的研究催生了算法（algorithm）一词。

阅读全文

看到这些，我又激动了，数学之美，不正是美在这些地方吗？我们不是要做数学家，但这并不妨碍我们站在门口向里张望……

近来在Windows下用WSAEventSelect时，碰到一个棘手的问题，当然现在已经解决了。

问题描述：

一个Server，一个ClientA，一个ClientB，Server用WSAEventSelect模型监听（只有监听，没有读写），ClientA在连接Server后，ClientA对应的EventA被触发，Server的WSAWaitForMultipleEvents等待到EventA，ClientB连接Server时，TCP三次握手成功，ClientB与Server的TCP状态被置为ESTABLISHED，然而Server的WSAWaitForMultipleEvents没有等待到EventB被触发。

用netstat看了一下，ClientB与Server的状态是ESTABLISHED，此时如果ClientB退出，由于Server无法正常Close该连接，因此Server的状态不是TIME_WAIT而是CLOSE_WAIT（持续2小时），Client的状态是FIN_WAIT_2（持续10分钟）。

我尝试将ClientA主动关闭后再次连接Server，Server的WSAWaitForMultipleEvents在wait到EventA之后，EventB此时也被触发。

开始一直以为问题的根源在于WSAEventSelect的使用上，毕竟，之前没有系统写过类似的代码，难免怀疑到事件模型的使用上。多方查阅资料，最后还是没有发现类似问题的解决方案。

又跟了一上午之后，Kevin开始怀疑是多线程使用的问题，我看了一下，的确没有对event的多线程操作进行处理，但因为在另一个应用中，使用了同样的模块，却没有该问题。最后考虑必要性时还是放弃了加临界资源，无视多线程同步问题。Kevin本来劝我换个模型，但我固执的认为要做就把这事儿做好。因为下午还要回学校一趟，就想尽快搞定，毕竟因为这一块已经把Kevin的进度拖了一周了，心下还是过意不去，而且隐约感觉到离问题的解决越来越近了。

问题分析：

在对着WSAWaitForMultipleEvents思考了半天之后，忽然开窍了，如果ThreadA在WSAWaitForMultipleEvents时，只有一个EventA被WSAEventSelect并set到signaled状态，则该EventA会被wait成功，ThreadA处理EventA之后继续阻塞在WSAWaitForMultipleEvents。此时，ThreadB通过WSAEventSelect将EventB初始化为nonsignaled状态，之后即使EventB被set为signaled状态，但ThreadA的WSAWaitForMultipleEvents因为处于阻塞状态，不可能刷新事件集，也就不可能wait到EventB，最终导致了ClientB的请求无法被响应。如果EventA被触发则会被ThreadA等待到，WSAWaitForMultipleEvents返回后再次进入时事件集已经被刷新，EventB被wait到也就不难理解了。

问题解决：

说到底是因为当ThreadA阻塞在WSAWaitForMultipleEvents处之时，事件集的变更无法立即得到体现。如果允许上层应用随时create或close一些event，则WSAWaitForMultipleEvents就不应该无限阻塞下去。

因此最后的一个解决方法就是让WSAWaitForMultipleEvents超时返回并Sleep一段时间，当WSAWaitForMultipleEvents再次进入时事件集得以更新。

想了一下，另一个应用中之所以没出现该问题也只是个巧合，因为该应用中ThreadB的两次WSAEventSelect间隔很短，在ThreadA获得时间片之前已经确定了事件集。

说白了这也不是一个什么大问题，甚至谈不上任何难度，但是因为之前对WSAEventSelect没有一个清晰的概念，因此在发现和分析问题上花费了大量时间，加上在VS2005调试过程中，有个别文件更新时没有被重新编译，也耗费了很多无谓的时间，以至于我们都在考虑是不是要放弃IDE，因为我们确实太依赖IDE了，有些TX为了稳妥，每次都是“重新生成整个解决方案”，如果一个解决方案有几千个文件、几十万行的代码，估计重编一次也要花个几分钟吧。

总结：

1. netstat观察的网络连接处于ESTABLISHED状态并不意味着逻辑连接被accept，只是表明客户端connect的TCP物理连接（三次握手）被服务器端ack，如果服务器没有accept到该连接，证明网络模块代码有问题；
2. 多线程怎么都是个问题，线程同步尽量避免，毕竟，用Kevin的话来说，加锁是丑陋的。但在涉及到同步问题时，还是权衡一下，我这儿之所以最后没有加临界区，是因为事件主要是在ThreadA中处理，ThreadB中只有create操作，而且ThreadA对事件集的刷新要求不是那么严格，也就不考虑加临界区了；
3. 如果能力和条件允许的话，放弃IDE吧，IDE的确不是个好东西，我主要是指在编译链接的时候，如果作为编辑器说不定还会好用:)。

个人网站http://www.yulefox.com用的主机最近从据说要黑屏的Windows换成了Debian，还在调整，估计明天能弄好，内容肯定比Cppblog杂的多，谈点技术的还是会同步更新到http://www.cppblog.com/fox。

本文同时发布在http://www.yulefox.com和http://www.cppblog.com/fox。

十天之前，在CPPBLOG上写了一篇消息映射机制的简单实现，有同学提到该实现不支持成员函数。这个问题我也考虑到了，既然被提出来，不妨把实现提供出来。

需要说明的是，我本身对template比较不感冒，不过Kevin Lynx对template感冒，而且写过关于成员函数指针的问题，想了很久，如果支持成员函数指针，不用模板是不行了。

此处对成员函数的支持还不涉及对函数参数的泛化，因为我这个消息映射暂时不需要参数泛化，下面的代码应该不需要过多的解释了。

不可否认，模板给了你更大的想象空间，很多东西，还是不要一味排斥的好:)。