詳解什么是數(shù)據(jù)驅(qū)動編程
前言:
最近在學(xué)習(xí)《Unix編程藝術(shù)》。以前粗略的翻過,以為是介紹unix工具的?,F(xiàn)在認(rèn)真的看了下,原來是介紹設(shè)計原則的。它的核心就是***章介紹的unix的哲學(xué)以及17個設(shè)計原則,而后面的內(nèi)容就是圍繞它來展開的。以前說過,要學(xué)習(xí)適合自己的資料,而判斷是否適合的一個方法就是看你是否能夠讀得下去。我對這本書有一種相見恨晚的感覺。推薦有4~6年工作經(jīng)驗的朋友可以讀一下。
正題:
作者在介紹Unix設(shè)計原則時,其中有一條為“表示原則:把知識疊入數(shù)據(jù)以求邏輯質(zhì)樸而健壯”。結(jié)合之前自己的一些經(jīng)驗,我對這個原則很有共鳴,所以先學(xué)習(xí)了數(shù)據(jù)驅(qū)動編程相關(guān)的內(nèi)容,這里和大家分享出來和大家一起討論。
數(shù)據(jù)驅(qū)動編程的核心
數(shù)據(jù)驅(qū)動編程的核心出發(fā)點是相對于程序邏輯,人類更擅長于處理數(shù)據(jù)。數(shù)據(jù)比程序邏輯更容易駕馭,所以我們應(yīng)該盡可能的將設(shè)計的復(fù)雜度從程序代碼轉(zhuǎn)移至數(shù)據(jù)。
真的是這樣嗎?讓我們來看一個示例。
假設(shè)有一個程序,需要處理其他程序發(fā)送的消息,消息類型是字符串,每個消息都需要一個函數(shù)進(jìn)行處理。***印象,我們可能會這樣處理:
- 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 ", msg_type);
 - }
 - }
 
上面的消息類型取自sip協(xié)議(不完全相同,sip協(xié)議借鑒了http協(xié)議),消息類型可能還會增加??粗35牧鞒炭赡苡悬c累,檢測一下中間某個消息有沒有處理也比較費勁,而且,沒增加一個消息,就要增加一個流程分支。
按照數(shù)據(jù)驅(qū)動編程的思路,可能會這樣設(shè)計:
- typedef void (*SIP_MSG_FUN)(const char *);
 - typedef struct __msg_fun_st
 - {
 - const char *msg_type;//消息類型
 - SIP_MSG_FUN fun_ptr;//函數(shù)指針
 - }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 ", msg_type);
 - }
 
下面這種思路的優(yōu)勢:
1、可讀性更強(qiáng),消息處理流程一目了然。
2、更容易修改,要增加新的消息,只要修改數(shù)據(jù)即可,不需要修改流程。
3、重用,***種方案的很多的else if其實只是消息類型和處理函數(shù)不同,但是邏輯是一樣的。下面的這種方案就是將這種相同的邏輯提取出來,而把容易發(fā)生變化的部分提到外面。
隱含在背后的思想:
很多設(shè)計思路背后的原理其實都是相通的,隱含在數(shù)據(jù)驅(qū)動編程背后的實現(xiàn)思想包括:
1、控制復(fù)雜度。通過把程序邏輯的復(fù)雜度轉(zhuǎn)移到人類更容易處理的數(shù)據(jù)中來,從而達(dá)到控制復(fù)雜度的目標(biāo)。
2、隔離變化。像上面的例子,每個消息處理的邏輯是不變的,但是消息可能是變化的,那就把容易變化的消息和不容易變化的邏輯分離。
3、機(jī)制和策略的分離。和第二點很像,本書中很多地方提到了機(jī)制和策略。上例中,我的理解,機(jī)制就是消息的處理邏輯,策略就是不同的消息處理(后面想專門寫一篇文章介紹下機(jī)制和策略)。
數(shù)據(jù)驅(qū)動編程可以用來做什么:
如上例所示,它可以應(yīng)用在函數(shù)級的設(shè)計中。
同時,它也可以應(yīng)用在程序級的設(shè)計中,典型的比如用表驅(qū)動法實現(xiàn)一個狀態(tài)機(jī)(后面寫篇文章專門介紹)。
也可以用在系統(tǒng)級的設(shè)計中,比如DSL(這方面我經(jīng)驗有些欠缺,目前不是非常確定)。
它不是什么:
1、 它不是一個全新的編程模型:它只是一種設(shè)計思路,而且歷史悠久,在unix/linux社區(qū)應(yīng)用很多;
2、它不同于面向?qū)ο笤O(shè)計中的數(shù)據(jù):“數(shù)據(jù)驅(qū)動編程中,數(shù)據(jù)不但表示了某個對象的狀態(tài),實際上還定義了程序的流程;OO看重的是封裝,而數(shù)據(jù)驅(qū)動編程看重的是編寫盡可能少的代碼。”
書中的值得思考的話:
數(shù)據(jù)壓倒一切。如果選擇了正確的數(shù)據(jù)結(jié)構(gòu)并把一切組織的井井有條,正確的算法就不言自明。編程的核心是數(shù)據(jù)結(jié)構(gòu),而不是算法。——Rob Pike
程序員束手無策。。。。。只有跳脫代碼,直起腰,仔細(xì)思考數(shù)據(jù)才是***的行動。表達(dá)式編程的精髓。——Fred Brooks
數(shù)據(jù)比程序邏輯更易駕馭。盡可能把設(shè)計的復(fù)雜度從代碼轉(zhuǎn)移至數(shù)據(jù)是個好實踐。——《unix編程藝術(shù)》作者。
原文鏈接:http://www.cnblogs.com/chgaowei/archive/2011/08/03/2126724.html
【編輯推薦】















 
 
 








 
 
 
 