C/C++中一个简朴的enum手法(idiom)

副标题#e#

本日写措施的时候，又用到这个idiom了，于是顺便贴出来。这个idiom蛮简朴的，预计很 多人都用过。本日主要是贴出来给新手参考（内行们就甭费时看此帖了）。

为了说明这个手法详细该咋用，咱举一个简朴的例子来说事儿。例如说要开拓一个网络程 序，个中需要统计各类网络协议的数据包数量。

★版本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，第4个是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中常量的顺序即可，其它代码不消动。

#p#副标题#e#

★版本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<int> vctCntProto(PROTO_NUM);

文章来历：

http://program-think.blogspot.com/2009/04/c-cxx-enum-idiom.html