数据驱动编程

“数据的表现形式是编程的根本”

“更普遍的是，战略上突破常来自数据或表的重新表达――这是程序的核心所在。

如果提供了程序流程图，而没有表数据，我仍然会很迷惑。而给我看表数据，往往就

不再需要流程图，程序结构是非常清晰的。”

“由于缺乏空间而绞尽脑汁的编程人员，常常能通过从自己的代码中挣脱出来，

回顾、分析实际情况，仔细考虑程序的数据，最终获得非常好的结果。实际上，数据

的表现形式是编程的根本。”

――《The Mythical Man-Month》Frederick P. Brooks. Jr.

数据驱动编程，也叫元编程。

数据驱动编程的核心出发点是相对于程序逻辑，人类更擅长于处理数据。

数据比程序逻辑更容易驾驭，所以我们应该尽可能的将设计的复杂度从程序代码转移至数据。

数据驱动编程需要将代码和数据结构划分清楚。在改变程序逻辑的时候，只要改变数据结构中的数据，

而不需要改变代码。数据驱动编程不同于面向对象编程。数据驱动编程中，数据不仅是对象的状态，

而且还定义了程序的控制流。数据驱动编程首先关注的是编写尽可能少的代码。

而面向对象编程首先关注的是封装。数据驱动编程也不是状态机编写。

状态机当然也可以用表的形式来定义。

假设有一个程序，需要处理其他程序发送的消息，消息类型是字符串，每个消息都需要一个函数进行处理。第一印象，我们可能会这样处理：

void msg_proc(const char *msg_type, const char *msg_buf)

{

if (0 == strcmp(msg_type, "inivite"))

{

inivite_fun(msg_buf);

}

else if (0 == strcmp(msg_type, "tring_100"))

{

tring_fun(msg_buf);

}

else if (0 == strcmp(msg_type, "ring_180"))

{

ring_180_fun(msg_buf);

}

else if (0 == strcmp(msg_type, "ring_181"))

{

ring_181_fun(msg_buf);

}

else if (0 == strcmp(msg_type, "ring_182"))

{

ring_182_fun(msg_buf);

}

else if (0 == strcmp(msg_type, "ring_183"))

{

ring_183_fun(msg_buf);

}

else if (0 == strcmp(msg_type, "ok_200"))

{

ok_200_fun(msg_buf);

}

。。。。。。

else if (0 == strcmp(msg_type, "fail_486"))

{

fail_486_fun(msg_buf);

}

else

{

log("未识别的消息类型%s\n", msg_type);

}

}

上面的消息类型取自sip协议（不完全相同，sip协议借鉴了http协议），消息类型可能还会增加。看着常常的流程可能有点累，检测一下中间某个消息有没有处理也比较费劲，而且，没增加一个消息，就要增加一个流程分支。
按照数据驱动编程的思路，可能会这样设计：

typedef void (*SIP_MSG_FUN)(const char *);
typedef struct __msg_fun_st

{

const char *msg_type;//消息类型

SIP_MSG_FUN fun_ptr;//函数指针

}msg_fun_st;
msg_fun_st msg_flow[] =

{

{"inivite", inivite_fun},

{"tring_100", tring_fun},

{"ring_180", ring_180_fun},

{"ring_181", ring_181_fun},

{"ring_182", ring_182_fun},

{"ring_183", ring_183_fun},

{"ok_200", ok_200_fun},
。。。。。。

{"fail_486", fail_486_fun}

};
void msg_proc(const char *msg_type, const char *msg_buf)

{

int type_num = sizeof(msg_flow) / sizeof(msg_fun_st);

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

{

if (0 == strcmp(msg_flow[i].msg_type, msg_type))

{

msg_flow[i].fun_ptr(msg_buf);

return ;

}

}

log("未识别的消息类型%s\n", msg_type);

}

下面这种思路的优势：

1、可读性更强，消息处理流程一目了然。

2、更容易修改，要增加新的消息，只要修改数据即可，不需要修改流程。

3、重用，第一种方案的很多的else if其实只是消息类型和处理函数不同，但是逻辑是一样的。下面的这种方案就是将这种相同的逻辑提取出来，而把容易发生变化的部分提到外面。

隐含在背后的思想：

很多设计思路背后的原理其实都是相通的，隐含在数据驱动编程背后的实现思想包括：

1、控制复杂度。通过把程序逻辑的复杂度转移到人类更容易处理的数据中来，从而达到控制复杂度的目标。

2、隔离变化。像上面的例子，每个消息处理的逻辑是不变的，但是消息可能是变化的，那就把容易变化的消息和不容易变化的逻辑分离。

3、机制和策略的分离。和第二点很像，本书中很多地方提到了机制和策略。上例中，我的理解，机制就是消息的处理逻辑，策略就是不同的消息处理（后面想专门写一篇文章介绍下机制和策略）。

数据驱动编程可以用来做什么：

如上例所示，它可以应用在函数级的设计中。

同时，它也可以应用在程序级的设计中，典型的比如用表驱动法实现一个状态机（后面写篇文章专门介绍）。

也可以用在系统级的设计中，比如DSL（这方面我经验有些欠缺，目前不是非常确定）。

它不是什么：

1、 它不是一个全新的编程模型：它只是一种设计思路，而且历史悠久，在unix/linux社区应用很多；

2、它不同于面向对象设计中的数据：“数据驱动编程中，数据不但表示了某个对象的状态，实际上还定义了程序的流程；OO看重的是封装，而数据驱动编程看重的是编写尽可能少的代码。”

书中的值得思考的话：

数据压倒一切。如果选择了正确的数据结构并把一切组织的井井有条，正确的算法就不言自明。编程的核心是数据结构，而不是算法。——Rob Pike

程序员束手无策。。。。。只有跳脱代码，直起腰，仔细思考数据才是最好的行动。表达式编程的精髓。——Fred Brooks

数据比程序逻辑更易驾驭。尽可能把设计的复杂度从代码转移至数据是个好实践。——《unix编程艺术》作者。