★版本1

假设一开始只需要处理HTTP和FTP两种协议。有些同学不假思索，立即会声明如下两个整数用于统计：

int nCntHttp = 0;
int nCntFtp = 0;

猛一看，似乎没啥问题。但是，如果需求发生变更，又要增加两种协议：SMTP和SSH。然后，该同学会继续扩展上述代码，变为如下：

int nCntHttp = 0;
int nCntFtp = 0;
int nCntSmtp = 0;
int nCntSsh = 0;

这时候，问题开始显露出来了。比方说要打印上述4统计值，就得写4个printf；再假如要用断言确保所有统计值大于零，也得写4个assert。这都是挺烦人的事儿。（当然啦，有些同学会把4个变量的打印写在一个printf中，但还是一样烦人）

★版本2

这可咋办捏？某些同学就灵机一动，把上述代码修改为数组形式，上述的4个统计值依次放入数组中。具体如下：

int nCntProto[4];
/* 第0个是HTTP，第1个是FTP，第2个是SMTP，第3个是SSH */

这样，无论是打印还是断言，都可以用for循环搞定，貌似挺方便的。但这么一来，引入了另一个问题。假设我在程序中要用到SMTP的统计数字，就得这么写代码：nCntProto[2]。这就造成了很不雅观的“Magic Number”！要知道，Magic Number可是代码的臭味之一啊（其弊端在“这里”曾经介绍过）。万一将来，数组中的存放顺序发生变化，那就完蛋了：好多用到Magic Number的代码都得跟着改。一旦漏改某处，引出Bug无数！

★版本3

为了消除Magic Number，增加代码可读性和可维护性，有些同学开始打起enum的主意。在代码中增加了一组enum，具体如下：

enum PROTO
{
  PROTO_HTTP,
  PROTO_FTP,
  PROTO_SMTP,
  PROTO_SSH,
};
int nCntProto[4];

这样，如果我需要用到SMTP的统计数字，我就不用写nCntProto[2]，而是写nCntProto[PROTO_SMTP]。这样，可读性明显好多了。即使将来数组中的存放顺序发生变化，也没关系：只需稍微调整enum中常量的顺序即可，其它代码不用动。

★版本4

但是，还是有一个不爽的地方。定义数组的语句用到了“4”这个Magic Number。万一将来需求继续变更，继续增加协议，那这个数字还得不断调整。不爽！

这时候，终极版本隆重登场。请看如下代码：

enum PROTO
{
  PROTO_HTTP,
  PROTO_FTP,
  PROTO_SMTP,
  PROTO_SSH,
  PROTO_NUM /* 表示协议数量 */
};
int nCntProto[PROTO_NUM];

这种写法的好处在于，没有任何一个Magic Number。不管是引用某个统计值还是循环遍历数组，都使用的是定义好的常量。

当需求变更，需要增加新的协议，只要往enum中增加相应的enum常量即可（但要记得保证PROTO_NUM位于enum定义的末尾）。由于PROTO_NUM会自动跟着增长，所以其它的代码几乎不会受到影响。

★C++的补充说明

上述代码同时适用于C和C++。不过，对于某些C++程序员，或许看不惯原始数组，觉得STL的容器类看起来比较顺眼。那也没啥大关系：只要把上述代码的数组声明修改为如下，其它的代码基本照旧。

std::vector vctCntProto(PROTO_NUM);