前言

因为之前一直处在游戏开发行业，由于种种原因一直对软件工程中的项目管理、项目开发方法缺乏体验。虽然项目中也曾倡导编写更多的文档，无论是模块说明文档还是设计文档，但效果一直不好。不甚理想的地方主要体现在文档的规范性欠缺、不统一、浮于表面没有实质内容。文档的编写缺乏详尽的方法指导，那么所谓的设计文档要么是用来敷衍上级要么就是随着开发人员的水平不一而千差万别。

当我开始目前这个非游戏项目时，我也曾想，前期做好结构设计，制定好关键问题的解决方案，那么要完成这个项目就不在话下了。但是我很快就面临了一个问题：需求不定。回想身处游戏公司的那些日子，程序员总是抱怨策划需求变更过快过多，在每一次策划提出一个需求变更时，谨慎的程序员都会再三让策划保证：放心，不会变了。而我面临的问题则更为严峻。我意识到，项目的需求，就连用户也无法一一罗列出来。我们需要的是需求调研。但就算你将客户的所有需求全部挖掘出来后（这几乎不可能，因为他们自己也不太清楚自己想要什么），当你交付了第一个软件版本，几乎可以肯定客户会提出一大堆的需求变更：我要的不是这个，我要的那个怎么没有，哦，我当初以为你说的是另一个意思。

当然，需求调研这种工作不是让程序员去做的（那会更悲剧，无论是对客户还是对程序员而言，他们都是在对牛弹琴）。但需求的不确定性也总是存在的。

事实上，需求变化本身就是一个很正常的现象。我一向愿意更悲观地处理软件开发方面的问题，所谓小心使得万年船。基于此，我决定摆好心态学学软件开发的方法学。

概要

本文简要描述、总结了RUP开发方法学的主要内容，结合我自己的感受阐述了一些RUP的核心原则。我相信我所理解的内容是肤浅的，对于非代码的表达我更相信其是存在歧义的。所以本文仅当是一种经验参考，不必当真。

RUP据传是用于指导大型甚至超大型项目开发的，我们做的不是这样规模的项目。但是我们需要记录下整个项目的开发过程，通过这个过程中产出的工件任何一个人可以看出这个项目是如何实现出来的，其目的在于规避唯有从海量代码中才能熟悉项目实现这种问题。这里出现了一个概念：工件，其指的是软件项目开发过程中任何留下记录的事物，例如文档、图、代码等。RUP的一个重要思想，在于其整个软件开发过程都是可推导的。例如我们通常说的软件架构，或小一点的模块结构，都是通过开发过程中前面阶段产出的工件推导得出，而不是凭借程序员的经验拍脑袋想出来的（经验不太可靠，并且千差万别，而推导意味着将每个环节变得可靠）。我们借助RUP的这个特性，创建这些工件，用以建立起软件实现的可靠知识库。

RUP概览

以下均摘自<Thinking in UML>中对RUP的描述：

统一过程归纳和集成了软件开发活动中的最佳实践，它定义了软件开发过程中最重要的阶段和工作（四个阶段和九个核心工作流），定义了参与软件开发过程的各种角色和他们的职责，还定义了软件生产过程中产生的工件，并提供了模板。最后，采用演进式软件生命周期（迭代）将工作、角色和工件串在一起，形成了统一过程。

统一过程是一种追求稳定的软件方法，它追求开发稳定架构，控制变更

统一过程集成了面向对象方法、UML语言、核心工作流、工件模板和过程指导等知识

简单来说，RUP作为一种软件项目开发方法学，它定义了软件开发的每一个过程，最重要的是它指导了在每一个过程需要产出什么，这些产出又是怎样得到。它试图规范化整个流程，以规避需求变更，项目参与者水平不一等带来的项目不可控等问题，以期一个软件产品稳定地开发出来。在一个项目开发过程中，最核心的资源是人，最不可控的亦是人。

RUP过程与实践

我觉得要快速学习一种知识，需要首先获得这门知识的总体框架。另一方面，在我们获得更多信息后，我们需要挖掘出这门知识的核心思想。学习RUP我觉得从这两方面入手是相对比较快速和有效的手段。

RUP框架

RUP定义了软件开发过程的四个阶段，以及9个工作流程。一张极为经典的RUP开发过程框架图如下：

RUP将整个软件开发过程分为四个阶段：

• 先启(Inception)、
• 精化(Elaboration)
• 构建(Construction)
• 产品化(Transition)

每一个阶段的工作分为9个流程：

• 业务建模
• 需求
• 分析设计
• 实施
• 测试
• 部署
• 配置与变更管理
• 项目管理
• 环境

其中，前6个流程被统称为”engineering disciplines”，后3个流程被称为”supporting disciplines”。当然，我们主要关注前6个流程。那么，这些工作流程和开发阶段又有什么关系呢？上图中其实已经阐明了这些关系。

RUP指导迭代开发。在软件开发的这4个阶段中，每一个阶段会被分为若干次迭代。而每一次迭代则涵盖了这9个工作流程。随着开发阶段向产品化靠近，自然而然地，需求的变更、增加自然会减少，所以从图中可以看出，开发过程越到后期，其工作流程中关于需求的工作则越少。同样，在先启阶段，其需求相关的工作则占据了该阶段的主要工作内容。

RUP中的迭代要求在每一次迭代中，都会完整地实施一遍整个工作流程。在软件实施阶段，甚至会在每一个迭代过程完后输出一个可运行的软件版本。这个版本可能会被交付给客户，以期进一步地在功能需求上取得与客户一致的意见。这倒是同敏捷开发有点类似。

既然制定了工作流程，那每一个工作流程该如何去实施呢？RUP制定了每个工作流程需要参与的角色，这些角色需要从事的活动，以及这些活动产生的工件。

这句话实际上反映了RUP的一个重要信息，摘自wiki：

RUP is based on a set of building blocks, or content elements, describing what is to be produced, the necessary skills required and the step-by-step explanation describing how specific development goals are to be achieved. The main building blocks, or content elements, are the following:

• Roles (who) – A Role defines a set of related skills, competencies and responsibilities.
• Work Products (what) – A Work Product represents something resulting from a task, including all the documents and models produced while working through the process.
• Tasks (how) – A Task describes a unit of work assigned to a Role that provides a meaningful result.

RUP建模

在我看来，RUP每个工作流程所完成的工作，就是一个建模的过程。所谓建模，简单来说就是将需要描述的事物通过更系统的形式表达出来，以期获得对该事物更深入的理解。<Thinking in UML>中定义建模概念为：

建模(modeling)，是指通过对客观事物建立一种抽象的方法用以表征事物并获得对事物本身的理解，同时把这种理解概念化，将这些逻辑概念组织起来，构成一种对所观察的对象的内部结构和工作原理的便于理解的表达。

在这里，建模的过程需要使用一些工具。在RUP中建模使用UML来完成。在<Thinking in UML>中讲述了UML的核心模型，包括：

• 业务用例模型
• 概念用例模型
• 系统用例模型
• 领域模型
• 分析模型
• 软件架构和框架
• 设计模型
• 组件模型
• 实施模型

可能在大家的普遍认识中，UML无非就是几种图，并且粗看一眼理解起来也不困难，甚至还能用来画画类图做下代码结构设计。但UML的作用不仅仅如此。

以上所描述的UML核心模型中，每个模型并不单指的的是一种UML图。每个模型实际上都会包含几种UML图，会包含若干张UML图。这些模型基本上渗透于RUP的9个工作流程中，只不过不同的工作流程使用的模型比重不一而已。

例如在“分析设计”工作流程中，可能会使用到系统用例模型、分析模型、软件架构和框架、设计模型等，而业务用例模型可能在这个流程中根本不会用到；相反，业务用例模型则可能在“业务建模”流程中被广泛使用。

前已述及在RUP的每个工作流程中，RUP定义了该流程需要参与的角色，以及这些角色需要进行的活动，例如这里可以看看“分析设计”流程中的角色和活动集（摘自<Thinking in UML>）：

相应的，在该工作流程中需要产出的工件集为（摘自<Thinking in UML>）：

既然使用了UML作为建模工具，所以可以简单地说这些工件主要就是UML图，当然也会有其他文档性质的事物，例如网络协议结构、数据库表等UML无法描述的东西则通过普通文字性文档描述。

RUP最佳实践

到目前为止我们已经了解到RUP定义了开发过程(phase)，定义了每个过程包含的若干工作流程，还定义了每个工作流程需要哪些角色从事哪些活动来完成哪些工件。除此之外，RUP还提供了6条最佳实践用以指导软件开发：

• 迭代开发
• 管理需求
• 使用基于组件的架构
• 可视建模
• 持续的质量验证
• 控制变更

这些实践在我看来仅仅是一些项目开发的指导原则，它们渗透到每一个过程，每一个工作流程。在项目过程中实践这些原则，用以确保项目的成功。例如我们使用UML建模，以达到“可视建模”。我们通过建立需求用例，以“管理需求”。

RUP核心思想

似乎没有文档来专门阐述RUP的核心思想，但我觉得掌握其核心思想才是学习的要点所在。要理解一种软件开发方法学的核心思想，其实最好是将其与别的方法学做比较。这里先就我的一些感想做阐述。

用例驱动

用例驱动指的是整个软件项目的推进过程，是依靠“用例”来完成。<Thinking in UML>：

在实际的软件项目中，一个软件要实现的功能通过用例来捕获，接下来的所有分析、设计、实现、测试都由用例来取得，即以实现用例为目标。在统一过程中用例能够驱动的不仅仅是分析设计。

用例简单来说就是描述了一个系统功能。但必须注意的是，这仅仅是它定义的一小部分。用例主要分布在“业务建模”、“需求”、“分析设计”这些工作过程中。在不同的过程中用例的粒度和性质都不一样。例如对于一个借书系统而言，在业务建模阶段，我们可以获取出一个“借书”用例，其系统边界甚至不是系统而可能仅关注这个业务本身（因为这个阶段还没有考虑到计算机如何实现这个借书业务）；在系统分析阶段，我们就可以将“借书”这个用例细化为用户和计算机软件系统的交互；进一步地，我们可能会进一步精化这个用例，例如用户通过网页终端“借书”。（这里描述了很多建模的细节，可不必深究，本文只给出一个概要性的介绍）

我们说用例驱动软件开发，但它如何驱动的呢？我在实际的建模过程中，最明显的感受就是用例驱动了整个建模过程。

• 在需求分析阶段，我以系统使用者的角度绘制出了一份用例图，用于表达使用者对该系统的需求
• 然后我绘制序列图（活动图等）来实现这些用例，也就是阐述使用者具体是如何与系统交互的
• 从之前的建模过程中我获得对系统功能需求方面的认识
• 基于前面的分析我可以绘制出系统用例图，以明确系统的各个功能需求
• 同样针对用例绘制用例实现图
• 用例本身应该包含更多的文档，因此我编写用例规约用以详细描述各个用例
• 从用例规约、用例实现中我可以抽离出一些分析类（较设计类更高抽象的类），包含用例场景中涉及到的实体，控制逻辑
• 细化这些分析类，将分析类组织起来形成系统，我会用界面类去衔接各个控制类
• 将得到的分析类按模块来划分，从而可以得到一个初步的系统架构
• 初步考虑系统实现，我甚至会得到一个初步是的系统部署图
• 回过头不断审视系统用例，以确认我是否实现了所有用例，这可以保证我的分析实现了所有需求，我不用枚举所有系统特性是否被我考虑周全，我仅需在已有用例图中核实
• 基于模块实现各个用例，或者基于分析类来实现系统用例
• 通过重新绘制以及核实用例，可以进一步精化分析类，分析类在很大程度上会一一对应到设计类，而设计类则对应到实际的代码
• 可以进入设计阶段，设计阶段会考虑到系统的实现细节，例如使用的语言，使用的框架等

进入设计阶段后，虽然可以进一步建模，得到会直接映射到代码的类图、序列图等，但这样的图在面临需求变更时，基本上会面临修改，这意味着维护这些文档需要耗费精力。所以，<Thinking in UML>中主张将精力放在维护分析类模型中，而通过其他约定实现从分析类到实际代码的转换。我觉得这个也在理。

规范化整个过程

我个人觉得RUP的一大特点在于规范化了整个软件开发过程，每一个步骤需要哪些角色参与，该干什么，怎么去干都有指导。加之这些活动的”可推导性“，这意味着不论参与角色属于什么水平，都可以稳固地推进项目进程。

此外，这种规范化也会给项目留下详细的演化过程。你可以明确地看到整个软件是如何演化出最终的产品代码，可以深入地理解项目代码中的设计。

总结

我只是一个RUP新手，即便如此，我依然不觉得RUP是软件开发的万能药。我相信任何软件开发方法都是有局限性的。我们在实际使用的时候也只是吸取其精华。不同的开发方法其适用范围也是不一样的。正如有人将RUP和XP做比较时说，如果你使用RUP去开一个杂货铺，在没开张之前你就已经破产了；同样如果你用XP去做飞机，飞机毁了十来次也许才能做出来（from <Thinking in UML> again）。

参考文档

• <Thinking in UML>
• RUP和IPD流程的优缺点
• IBM Rational Unified Process(wiki)
• 軟體工程三大陣營, RUP, CMMI, Agile Method
• XP与RUP的比较

原文地址： http://codemacro.com/2013/03/21/rup/
written by Kevin Lynx  posted at http://codemacro.com

MMO游戏对象属性设计

一般的MMORPG中，游戏对象主要包括怪物和玩家。这两类对象在经过游戏性方面的不断“进化”后，其属性数量及与之相关的逻辑往往会变得很巨大。如何将这一块做得既不损失效率，又能保证结构的灵活、清晰、可维护？本文将提供一种简单的结构。

Player:     +---------------+
            | property-1    |
            +---------------+
            | property-2    |
            +---------------+
            |     ...       |
            +---------------+
            | operator-1    |
            +---------------+
            | operator-2    |
            +---------------+
            | ...           |
            +---------------+

Entity:    +-------------------+
           | property-table    |
           +-------------------+
           | component-table   |
           +-------------------+
Property:  +-------------------+
           | observer-list     |
           +-------------------+
Component: +--------------------+
           | logic-related data |
           +--------------------+
           | logic-related func |
           +--------------------+

class Entity {
private:
    GUID id;
    std::map<std::string, IComponent*> components;
    std::map<std::string, Property*> properties;
};
class Property {
private:
    std::string name;
    Value val;
    std::vector<IComponent*> observers;
};
class IComponent {
public:
    virtual bool Operate (const Args &args) { return false; }
    virtual void OnNotify (const Property &property, const Args &args) {}
protected:
    std::string name;
    Entity *entity;
};

浅谈代码分层：构建模块化程序

模块化的程序是怎样的程序？我们可以说一个具有明显物理结构的软件是模块化的，例如带 插件的软件，一个完整的软件由若干运行时库共同构建；也可以说一个高度面向对象的库是 模块化的，例如图形引擎OGRE；也可以说一些具有明显层次结构的代码是模块化的。

模块化的软件具有很多显而易见的好处。在开发期，一个模块化的设计有利于程序员实现， 使其在实现过程中一直保持清晰的思路，减少潜伏的BUG；而在维护期，则有利于其他程序 员的理解。

在我看来，具有良好模块设计的代码，至少分为两种形式：

• 整体设计没有层次之分，但也有独立的子模块，子模块彼此之间耦合甚少，这些子模块 构成了一个软件层，共同为上层应用提供服务；
• 整个库/软件拥有明显的层次之分，从最底层，与应用业务毫无相关的一层，到最顶层， 完全对应用进行直接实现的那一层，每一个相对高层的软件层依赖于更底层的软件层， 逐层构建。

上述两种形式并非完全分离，在分层设计中，某一层软件层也可能由若干个独立的模块构成 。另一方面，这里也不会绝对说低层模块就完全不依赖于高层模块。这种双向依赖绝对不是 好的设计，但事实上我们本来就无法做出完美的设计。

本文将代码分层分为两大类：一是狭义上的分层，这种分层一般伴有文件形式上的表现；一 是广义上的分层，完全着眼于我们平时写的代码。

软件分层

软件分层一般我们可以在很多大型软件/库的结构图中看到。这些分层每一层本身就包含大 量代码。每个模块，每一个软件层都可能被实现为一个运行时库，或者其他以文件形式为 表现的东西。

Example Android

Android是Google推出的智能手机操作系统，在其官方文档中有Android的系统架构图：

这幅图中很好地反映了上文中提到的软件层次。整个系统从底层到高层分为Linux kernel， Libraries/Runtime，Application Framework，Applications。最底层的Kernel可以说与应 用完全不相关，直到最上层的Applications，才提供手机诸如联系人、打电话等应用功能。

每一层中，又可能分为若干相互独立（Again，没有绝对）的模块，例如Libraries那一层 中，就包含诸如Surface manager/SGL等模块。它们可能都依赖于Kernel，并且提供接口给 上层，但彼此独立。

Example Compiler

在编译器实现中，也有非常明显的层次之分。这些层次可以完全按照编译原理理论来划分。 包括：

• 词法分析：将文本代码拆分为一个一个合法的单词
• 语法分析：基于 词法分析 得到的单词流构建语法树
• 语义分析：基于 语法分析 得到的语法树进行语义上的检查等
• 生成器：基于 语义分析 结果（可能依然是语法树）生成中间代码
• 编译器：基于 生成器 得到的中间代码生成目标机器上的机器代码
• 链接器：基于 编译器 生成的目标代码链接成最终可执行程序

软件分层的好处之一就是对任务(task)的抽象，封装某个任务的实现细节，提供给其他 依赖模块更友好的使用接口。隔离带来的好处之一就是可轻易替换某个实现。 例如很 多UI库隔离了渲染器的实现，在实际使用过程中，既可以使用Direct X的渲染方式，也可 以使用OpenGL的实现方式。

但正如之前所强调，凡事没有绝对，凡事也不可过度。很多时候无法保证软件层之间就是单 向依赖。而另一些时候过度的分层也导致我们的程序过于松散，效率在粘合层之间绕来绕去 而消失殆尽。

在一个UI与逻辑模块交互比较多的程序中，因为并不想让两个模块发生太大的耦合，基本目标是
可以完全不改代码地换一个UI。逻辑模块需要在产生一些事件后通知到UI模块，并且在这个通知
里携带足够多的信息（数据）给接收通知的模块，例如UI模块。逻辑模块还可能被放置于与UI模
块不同的线程里。

最初的结构

最开始我直接采用最简单的方法，逻辑模块保存一个UI模块传过来的listener。当有事件发生时，
就回调相应的接口将此通知传出去。大致结构如下：

 /**//// Logic
 class EventNotify
 {
 public:
  virtual void OnEnterRgn( Player *player, long rgn_id );
 };

 /**//// UI
 class EventNotifyImpl : public EventNotify
 {
 };

 /**//// Logic
 GetEventNotify()->OnEnterRgn( player, rgn_id );

但是，在代码越写越多之后，逻辑模块需要通知的事件越来越多之后，EventNotify这个类开始
膨胀：接口变多了、不同接口定义的参数看起来也越来越恶心了。

改进

于是我决定将各种事件通知统一化：

struct Event
{
 long type; // 事件类型
  // 附属参数
};

这样，逻辑模块只需要创建事件结构，两个模块间的通信就只需要一个接口即可：

void OnNotify( const Event &event );

但是问题又来了，不同的事件类型携带的附属参数（数据）不一样。也许，可以使用一个序列化
的组件，将各种数据先序列化，然后在事件处理模块对应地取数据出来。这样做总感觉有点大动
干戈了。当然，也可以使用C语言里的不定参数去解决，如：

void OnNotify( long event_type, ... )

其实，我需要的就是一个可以表面上类型一样，但其内部保存的数据却多样的东西。这样一想，
模块就能让事情简单化：

template <typename P1, typename P2>
class Param
{
public:
 Param( P1 p1, P2 p2 ) : _p1( p1 ), _p2( p2 )
 {
 }
 
 P1 _p1;
 P2 _p2;
};

template <typename P1, typename P2>
void OnNotify( long event_type, Param<P1, P2> param );

GetNotify()->OnNotify( ET_ENTER_RGN, Param<Player*, long>( player, rgn_id ) );
GetNotify()->OnNotify( ET_MOVE, Param<long, long>( x, y ) );

在上面这个例子中，虽然通过Param的包装，逻辑模块可以在事件通知里放置任意类型的数据，但
毕竟只支持2个参数。实际上为了实现支持多个参数（起码得有15个），还是免不了自己实现多个
参数的Param。

幸亏我以前写过宏递归产生代码的东西，可以自动地生成这种情况下诸如Param1、Param2的代码。
如：

#define CREATE_PARAM( n ) \
 template <DEF_PARAM( n )> \
 struct Param##n \
 { \
  DEF_PARAM_TYPE( n ); \
  Param##n( DEF_FUNC_PARAM( n ) ) \
  { \
   DEF_MEM_VAR_ASSIGN( n ); \
  } \
  DEF_VAR_DEF( n ); \
 }

 CREATE_PARAM( 1 );
 CREATE_PARAM( 2 );

即可生成Param1和Param2的版本。其实这样定义了Param1、Param2的东西之后，又使得OnNotify
的参数不是特定的了。虽然可以把Param也泛化，但是在逻辑层写过多的模板代码，总感觉不好。

于是又想到以前写的一个东西，可以把各种类型包装成一种类型---对于外界而言：any。any在
boost中有提到，我只是实现了个简单的版本。any的大致实现手法就是在内部通过多态机制将各
种类型在某种程度上隐藏，如：

        class base_type
        {
        public:
            virtual ~base_type()
            {
            }
            virtual base_type *clone() const = 0;
        };
        
        template <typename _Tp>
        class var_holder : public base_type
        {
        public:
            typedef _Tp type;
            typedef var_holder<type> self;
        public:
            var_holder( const type &t ) : _t( t )
            {
            }

            base_type *clone() const
            {
                return new self( _t );
            }
        public:
            type _t;
        }

这样，any类通过一个base_type类，利用C++多态机制即可将类型隐藏于var_holder里。那么，
最终的事件通知接口成为下面的样子：

void OnNotify( long type, any data );

OnNotify( ET_ENTER_RGN, any( create_param( player, rgn_id ) ) );其中，create_param
是一个辅助函数，用于创建各种Param对象。

事实上，实现各种ParamN版本，让其名字不一样其实有点不妥。还有一种方法可以让Param的名字
只有一个，那就是模板偏特化。例如：

template <typename _Tp>
struct Param;

template <>
struct Param<void()>;

template <typename P1>
struct Param<void(P1)>

template <typename P1, typename P2>
struct Param<void(P1,P2)>

这种方法主要是通过组合出一种函数类型，来实现偏特化。因为我觉得构造一个函数类型给主模版，
并不是一种合情理的事情。但是，即使使用偏特化来让Param名字看起来只有一个，但对于不同的
实例化版本，还是不同的类型，所以还是需要any来包装。

实际使用

实际使用起来让我觉得非常赏心悦目。上面做的这些事情，实际上是做了一个不同模块间零耦合
通信的通道（零耦合似乎有点过激）。现在逻辑模块通知UI模块，只需要定义新的事件类型，在
两边分别写通知和处理通知的代码即可。

PS:
针对一些评论，我再解释下。其实any只是用于包装Param列表而已，这里也可以用void*，再转成
Param*。在这里过多地关注是用any*还是用void*其实偏离了本文的重点。本文的重点其实是Param：

OnNotify( NT_ENTER_RGN, ang( create_param( player, rgn_id ) ) );

->
void OnNotify( long type, any data )
{
 Param2<Player*, long> ParamType;
 ParamType *p = any_cast<ParamType>( &data );
 Player *player = p->p1;
 long rgn_id = p->p2;
}

下载相关代码

其实，我们都知道，auto_ptr这些东西始终是无法避免野指针和空指针带来的灾难。
SAFE_DELETE也不能阻止别人使用这个空指针。

在我看过的一些开源项目的代码中，这些代码给人的感觉就是别人总能详细地掌控各种资源
（包括指针及其他变量）的使用情况。相比之下，公司隔壁组的老大则显得保守很多。他要
求我们几乎要对所有指针的使用进行空值判断（野指针也判断不了），当然，各种成员变量
也要进行即使现在看上去没多大用的初始化。

也许，这样做后程序是不会挂掉了。但是，就我们的观点来看，这样反而会隐藏一些BUG。
为什么我们不能详尽地去管理一个指针？一个指针变为空了，总是因为在这之前发生了错误
。当然，野指针本身就是愚蠢代码产生的东西，这里没必要讨论。空指针之所以为空，也是
因为在很多时候我们把空作为失败/错误/无效的标志。

恰好上周我的一些代码就真的在空指针上出现了问题。外网的服务器随时会因为玩家的一些
临界操作行为而崩溃掉。虽然我通过修改脚本来屏蔽这个问题（因为不能说停机维护就停机
维护），但是总感觉程序是不安全的。人不吃点教训绝对不学乖。

后来我对这个问题彻底思考了一下。很多程序员都自认聪明。在写C++程序时，我从来不提
供没用的public接口，尤其是set/get。我也从来不对没必要的成员变量进行初始化。我给
的理由是对于这些东西我都有很清晰的把握，我为什么要做stupid的事情？

但是，我几乎从来没有界定，指针在哪些情况下需要去判断为空？函数的参数绝对不需要。
假如函数的参数就是个空指针，那是client程序员的责任。仅供模块内使用的指针（包含其
他资源）在内部使用时也不需要去判断。如果去判断了，那说明你对你自己写的模块都缺乏
精确的把握，证明你的设计思维不够清晰。

什么时候需要判断？当指针依赖于外部环境时，例如读配置文件、载入资源，因为外部因素
不确定不在自己控制范围内，那么进行判断。同样，当使用了其他模块返回的指针值时，也
需要判断。这个其实和“外部环境”属于同一种情况。因为我们对其他模块也不清楚，更为
隐蔽的是（随着其他模块的改变，将来会在你的模块里爆发崩溃错误），其他模块由别人维
护，其变化更不受自己控制。之前我对这一点界定不是很清楚，这也是我犯错的原因。

现在想想，像游戏服务器这种程序，里面塞着各种各样的游戏功能。无论是哪一个模块出现
个空指针访问出错的问题，都会直接让服务器崩掉。关键是这个结果经常伴随着玩家的损失
。所以理想状态下，把每一个模块都放置在单独的进程里，确实是很有好处的。

struct MyLess
{
    bool operator() ( long left, long right )
    {
        //...
    }
};

DEBUG模式下编译没问题，RELEASE模式下却出现C3848的错误。这就有点奇怪了，如果确实存在语法错误，
那么DEBUG和RELASE应该一样才对。查了下MSDN，C3848的错误是因为const限定符造成的，如：

const MyLess pr;
pr(); // C3848

于是，在operator()后加上const，就OK了。看了下VC std::map相关代码，以为是DEBUG和RELEASE使用了不
同的代码造成。但是我始终没找到不同点。另一方面，就STL内部的风格来看，应该不会把predicator处理
成const &之类的东西，全部是value形式的。奇怪了。

第二个问题，涉及到静态变量。这个东西给我的印象特别深刻，因为以前去一家外企应聘时被问到，当时
觉得那个LEADER特别厉害。回来后让我反思，是不是过多地关注了C++里的花哨，而漏掉了C里的朴素？导致
我至今对纯C存在偏好。

说正题，我现在有如下的文件关系：

// def.h
struct Obj
{
    Obj()
 {
  ObjMgr::AddObj( id, this );
 }
 int id;
};

struct ObjMgr
{
    static void AddObj( int id, Obj *t )
 {
  ObjTable[id] = t;
 }
 static std::map<int, Obj*> ObjTable;
};

static Obj _t;

// ObjMgr.cpp
#include "def.h"

static std::map<int, Obj*>::ObjMgr ObjTable;

// main.cpp
#include "def.h"

这里举的例子可能有点不恰当，我在一台没有编译器的机器上写的这篇文章。忽略掉这些旁支末节。我的意思，
就是想让Obj自己自动向ObjMgr里添加自己。我们都知道静态变量将在程序启动时被初始化，先于main执行之前。

上面代码有两个问题：

一、
代码没有按照我预期地执行，如果你按照我的意思做个测试，你的程序甚至在进main之前就crash了。我假定你
用的是VC，因为我没在其他编译器上试验过。问题就在于，Obj的构造依赖于ObjTable这个map对象。在调试过程
中我发现，虽然ObjTable拥有了内存空间，其this指针有效，但是，map对象并没有得到构造。我的意思是，Obj
的构造先于ObjTable构造（下几个断点即可轻易发现），那么在执行map::operator[]时，就出错了，因为这个时候
map里相关数据还没准备好。

那是否存在某种机制可以手动静态变量的初始化顺序呢？不知道。我最后怎样解决这个问题的？

二、
在还没有想到解决办法之前（不改变我的设计），我发现了这段代码的另一个问题：我在头文件里定义了静态
变量：static Obj _t; 这有什么问题？想想预编译这个过程即可知道，头文件在预编译阶段被文本展开到CPP
文件里，然后，ObjMgr.cpp和main.cpp文件里都将出现static Obj _t;代码。也就是说，ObjMgr.obj和main.obj
里都有一个文件静态变量_t。

看来，在头文件里放这个静态变量是肯定不对的。于是，我将_t移动到ObjMgr.cpp里：

// ObjMgr.cpp
#include "def.h"

static std::map<int, Obj*>::ObjMgr ObjTable;
static Obj _t;

按照这样的顺序定义后，_t的构造居然晚于ObjTable了。也就是说，放置于前面的变量定义，就意味着它将被
首先构造初始化。这样两个问题都解决了。

但是，谁能保证这一点特性？C标准文档里？还是VC编译器自己？

Kevin Lynx

Proactor和Reactor都是并发编程中的设计模式。在我看来，他们都是用于派发/分离IO操作事件的。这里所谓的
IO事件也就是诸如read/write的IO操作。"派发/分离"就是将单独的IO事件通知到上层模块。两个模式不同的地方
在于，Proactor用于异步IO，而Reactor用于同步IO。

摘抄一些关键的东西：

"
Two patterns that involve event demultiplexors are called Reactor and Proactor [1]. The Reactor patterns
involve synchronous I/O, whereas the Proactor pattern involves asynchronous I/O.
"

关于两个模式的大致模型，从以下文字基本可以明白：

"
An example will help you understand the difference between Reactor and Proactor. We will focus on the read
operation here, as the write implementation is similar. Here's a read in Reactor:

* An event handler declares interest in I/O events that indicate readiness for read on a particular socket ;
* The event demultiplexor waits for events ;
* An event comes in and wakes-up the demultiplexor, and the demultiplexor calls the appropriate handler;
* The event handler performs the actual read operation, handles the data read, declares renewed interest in
  I/O events, and returns control to the dispatcher .

By comparison, here is a read operation in Proactor (true async):

* A handler initiates an asynchronous read operation (note: the OS must support asynchronous I/O). In this
  case, the handler does not care about I/O readiness events, but is instead registers interest in receiving
  completion events;
* The event demultiplexor waits until the operation is completed ;
* While the event demultiplexor waits, the OS executes the read operation in a parallel kernel thread, puts
  data into a user-defined buffer, and notifies the event demultiplexor that the read is complete ;
* The event demultiplexor calls the appropriate handler;
* The event handler handles the data from user defined buffer, starts a new asynchronous operation, and returns
  control to the event demultiplexor.

"

可以看出，两个模式的相同点，都是对某个IO事件的事件通知(即告诉某个模块，这个IO操作可以进行或已经完成)。在结构
上，两者也有相同点：demultiplexor负责提交IO操作(异步)、查询设备是否可操作(同步)，然后当条件满足时，就回调handler。
不同点在于，异步情况下(Proactor)，当回调handler时，表示IO操作已经完成；同步情况下(Reactor)，回调handler时，表示
IO设备可以进行某个操作(can read or can write)，handler这个时候开始提交操作。

用select模型写个简单的reactor，大致为：

/**////
class handler
{
public:
    virtual void onRead() = 0;
    virtual void onWrite() = 0;
    virtual void onAccept() = 0;
}; 

class dispatch
{
public:
    void poll()
    {
        // add fd in the set.
        //
        // poll every fd
        int c = select( 0, &read_fd, &write_fd, 0, 0 );
        if( c > 0 )
        {
            for each fd in the read_fd_set
            {    if fd can read
                    _handler->onRead();
                if fd can accept
                    _handler->onAccept();
            } 

            for each fd in the write_fd_set
            {
                if fd can write
                    _handler->onWrite();
            }
        }
    } 

    void setHandler( handler *_h )
    {
        _handler = _h;
    } 

private:
    handler *_handler;
}; 

/**//// application
class MyHandler : public handler
{
public:
    void onRead()
    {
    } 

    void onWrite()
    {
    } 

    void onAccept()
    {
    }
}; 

在网上找了份Proactor模式比较正式的文档，其给出了一个总体的UML类图，比较全面：

根据这份图我随便写了个例子代码：

class AsyIOProcessor
{
public:
    void do_read()
    {
        //send read operation to OS
        // read io finished.and dispatch notification
        _proactor->dispatch_read();
    } 

private:
    Proactor *_proactor;
}; 

class Proactor
{
public:
    void dispatch_read()
    {
        _handlerMgr->onRead();
    } 

private:
    HandlerManager *_handlerMgr;
}; 

class HandlerManager
{
public:
    typedef std::list<Handler*> HandlerList; 

public:
    void onRead()
    {
        // notify all the handlers.
        std::for_each( _handlers.begin(), _handlers.end(), onRead );
    } 

private:
    HandlerList *_handlers;
}; 

class Handler
{
public:
    virtual void onRead() = 0;
}; 

// application level handler.
class MyHandler : public Handler
{
public:
    void onRead() 
    {
        // 
    }
}; 

Reactor通过某种变形，可以将其改装为Proactor，在某些不支持异步IO的系统上，也可以隐藏底层的实现，利于编写跨平台
代码。我们只需要在dispatch(也就是demultiplexor)中封装同步IO操作的代码，在上层，用户提交自己的缓冲区到这一层，
这一层检查到设备可操作时，不像原来立即回调handler，而是开始IO操作，然后将操作结果放到用户缓冲区(读)，然后再
回调handler。这样，对于上层handler而言，就像是proactor一样。详细技法参见这篇文章。

其实就设计模式而言，我个人觉得某个模式其实是没有完全固定的结构的。不能说某个模式里就肯定会有某个类，类之间的
关系就肯定是这样。在实际写程序过程中也很少去特别地实现某个模式，只能说模式会给你更多更好的架构方案。

最近在看spserver的代码，看到别人提各种并发系统中的模式，有点眼红，于是才来扫扫盲。知道什么是leader follower模式，
reactor, proactor，multiplexing，对于心中的那个网络库也越来越清晰。

最近还干了些离谱的事，写了传说中的字节流编码，用模板的方式实现，不但保持了扩展性，还少写很多代码；处于效率考虑，
写了个static array容器(其实就是template <typename _Tp, std::size_t size> class static_array { _Tp _con[size])，
加了iterator，遵循STL标准，可以结合进STL的各个generic algorithm用，自我感觉不错。基础模块搭建完毕，解析了公司
服务器网络模块的消息，我是不是真的打算用自己的网络模块重写我的验证服务器？在另一个给公司写的工具里，因为实在厌恶
越来越多的重复代码，索性写了几个宏，还真的做到了代码的自动生成:D。

对优雅代码的追求真的成了种癖好.  = =|

1.半同步/半异步（half-sync/half-async）：

在网上一份资料中引用了一本貌似很经典的书里的比喻：
”
许多餐厅使用 半同步/半异步 模式的变体。例如，餐厅常常雇佣一个领班负责迎接顾客，并在餐厅繁忙时留意给顾客安排桌位，
为等待就餐的顾客按序排队是必要的。领班由所有顾客“共享”，不能被任何特定顾客占用太多时间。当顾客在一张桌子入坐后，
有一个侍应生专门为这张桌子服务。
“

按照另一份似乎比较权威的文档的描述，要实现半同步/半异步模式，需要实现三层：异步层、同步层、队列层。因为很多操作
采用异步方式会比较有效率(例如高效率的网络模型似乎都采用异步IO)，但是异步操作的复杂度比较高，不利于编程。而同步
操作相对之下编程要简单点。为了结合两者的优点，就提出了这个模式。而为了让异步层和同步层互相通信(模块间的通信)，系
统需要加入一个通信队列。异步层将操作结果放入队列，同步层从队列里获取操作结果。

回过头来看看我之前写的那个select网络模型代码，个人认为基本上算是一个半同步半异步模式的简单例子：Buffer相当于通信
队列，网络底层将数据写入Buffer，上层再同步地从该队列里获取出数据。这样看来似乎也没什么难度。 = =

关于例子代码，直接引用iunknown给的：

//这就是一个典型的循环队列的定义，iget 是队列头，iput 是队列尾</STRONG>  
int clifd[MAXNCLI], iget, iput;   
int main( int argc, char * argv[] )  
{  
  ......  
  int listenfd = Tcp_listen( NULL, argv[ 1 ], &addrlen );  
  ......  
  iget = iput = 0;  
  for( int i = 0; i < nthreads; i++ ) {  
    pthread_create( &tptr[i].thread_tid, NULL, &thread_main, (void*)i );  
  for( ; ; ) {  
    connfd = accept( listenfd, cliaddr,, &clilen );  
    clifd[ iput ] = connfd;     // 接受到的连接句柄放入队列</STRONG>  
    if( ++iput == MAXNCLI ) iput = 0;    
  }  
}  
void * thread_main( void * arg )  
{  
  for( ; ; ) {  
    while( iget == iput ) pthread_cond_wait( ...... );  
    connfd = clifd[ iget ];     // 从队列中获得连接句柄</STRONG>  
    if( ++iget == MAXNCLI ) iget = 0;  
    ......  
    web_child( connfd );  
    close( connfd );  
  }  
} 

2.领导者/追随者（Leader/Followers）：

同样，给出别人引用的比喻：
”
在日常生活中，领导者/追随者模式用于管理许多飞机场出租车候车台。在该用例中，出租车扮演“线程”角色，排在第一辆的出
租车成为领导者，剩下的出租车成为追随者。同样，到达出租车候车台的乘客构成了必须被多路分解给出租车的事件，一般以先进
先出排序。一般来说，如果任何出租车可以为任何顾客服务，该场景就主要相当于非绑定句柄/线程关联。然而，如果仅仅是某些
出租车可以为某些乘客服务，该场景就相当于绑定句柄/线程关联。
“

其实这个更简单，我记得<unix网络编程>中似乎提到过这个。总之有一种网络模型(connection-per-thread?)里，一个线程用于
accept连接。当接收到一个新的连接时，这个线程就转为connection thread，而这个线程后面的线程则上升为accept线程。这里，
accept线程就相当于领导者线程，而其他线程则属于追随者线程。

iunknown 的例子代码：

int listenfd;  
int main( int argc, char * argv[] )  
{  
  ......  
  listenfd = Tcp_listen( NULL, argv[ 1 ], &addrlen );  
  ......  
  for( int i = 0; i < nthreads; i++ ){  
    pthread_create( &tptr[i].thread_tid, NULL, &thread_main, (void*)i );  
  }  
  ......  
}  
void * thread_main( void * arg )  
{  
  for( ; ; ){  
    ......  
    // 多个线程同时阻塞在这个 accept 调用上，依靠操作系统的队列</STRONG>  
    connfd = accept( listenfd, cliaddr, &clilen );  
    ......  
    web_child( connfd );  
    close( connfd );  
    ......  
  }  
}