公園2003年，秋。
西安。
晴，黃歷上寫——易出行，交友。
交大東二樓。
笑容，邪邪的笑容浮現在他英俊自信驕傲的臉上……
(以下轉正常)
今天是新碩士報道后的第一天，小P一早就高高興興的向教研室走去。“嗯，應該可以見到有趣的家伙吧。”他想。他很是期待見到新同學和結交新朋友。到Z老板辦公室和老板打過招呼后，他向實驗室走去。“聽說一個工作了3年的家伙已經到了，不知道是不是邪惡大叔啊。”小正太一邊走一邊邪惡的想著。推門進去發現一個高大沉穩老練的男人正在收拾電腦桌，呵呵，他的美人尖還透露出他的智慧。
“你好，我叫小P。”
男人回過頭：“呵呵，你好，我叫陳老C，你長得還真是年輕啊。”
“呵呵，幼稚，幼稚而已。”
“你是本科后直接上研的吧？”
“是啊是啊，聽說你工作了3年？”
“沒錯，我是96級的，工作3年以后又回學校來啦……”
……
“……我做過一些項目，有用C做的，有用C++做的……”老C和小P聊的不錯，感覺還挺投緣的。
“哦，我也用C寫過一些小的程序，C++課程也學習過，成績還挺不錯的。”小P開始吹牛了，“C++是C語言在面向對象方面的發展……”
“噢，這么說也沒有什么錯，開始的時候C++的確是C在面向對象方面的發展，但是……”老C開始給小P上課了，“現在C++其實是一個語言的聯邦，在它的內部存在4種不同的語言……”
“是嗎？”
“是的，這4種語言包括C——這是理所當然的——同時還包括面向對象部分，template部分和STL部分，每個部分都有其獨特的考慮問題的方式，有著自己獨到的習語和風格……”
“習語？風格？”
“是的。”老C解釋道，“我們學習編程語言就像學習一般的語言一樣——比如英語——如果你只是掌握了英語的基本語法你可以和英國人或者美國人自由的交流嗎？”
“我想應該不行吧，我想我可能不理解他們所說的……比如詞匯……”小P回答道。
“對，你有沒有發現當我們即使掌握了某種語言的語法也無法和其他人進行有效的交流的時候，就是說你對某段語言所表達的意思不了解的時候，一般都是如何不了解的？”
“哦？這個我還沒有仔細考慮過。讓我想想……”小P以手撐頭，陷入沉思狀……“我試著總結一下，應當是對以下幾方面不了解。”小P開始噴了。
- 對語言的基本單元無法理解，在英語里面應當是詞匯。
- 對句子無法理解，尤其是一些句型不了解，比如英語里面的too...to句型。
- 如果單詞理解了，句子也理解了，但是還是無法理解一段語言，那么應當是思維方式與說這段話的人有距離。
“沒錯！”老C稱贊道，“你還真是聰明啊，這么短時間就可以總結個子丑寅卯出來。”
“呵呵，哪里哪里，我就是比較油菜而已……”
“哈哈，那我們就拿你的總結與C++對比一下吧。”
- 單詞就像C++里面的慣用習語，比如virtual constructor或者PIMPL等
- 句型就像設計模式。
- 思維方法就是語言風格。
“不懂，什么是virtual constructor和PIMPL？什么又是設計模式？語言風格又是什么東東？”小P開始懷疑老C是火星人，他說的是漢語嗎？
“沒有關系，以后我們還有機會來討論那些C++常用的習語，現在我們就幾個常見的思維方式，也就是語言風格的問題舉幾個簡單的例子吧。”老C從實驗室的角落拉過來一塊白板，又找出一支彩筆開始在白板上畫了起來。
“我這里現在有一個簡單的問題，”老C在白板的上面寫下幾行文字。
設計一段代碼，這段代碼需要根據不同的輸入在屏幕上打印對應的水果名稱
“能具體一些嗎？”小P問。
“可以啊，我寫開始的一段代碼，你補全如何？”
“想考我嗎？沒有問題……呵呵。”
老C開始在白板上寫代碼，“我們意思意思就可以了，在這里我們使用C語言，所以是C語言的風格”。
“C？這個我還比較擅長。”小P現在有些想露一手。
“好吧，看看我們如何完成。”老C刷刷幾筆寫下了如下代碼。
typedef enum tagFRUIT{ORANGE, APPLE, BANANA} FRUIT;
void PrintFruitName(FRUIT fruit)
{
}
“嗯，容易……”小P開始完成
PrintFruitName()函數。
void PrintFruitName(FRUIT fruit)
{
switch (fruit)
{
case ORANGE:
pirntf("orange\n");
break;
case APPLE:
printf("apple\n");
break;
case BANANA:
printf("banana\n");
break;
default:
return;
}
}
“好了，我們的算法是這樣的，一個函數從某處——無論什么地方，鍵盤輸入也好，某個配置文件也好——讀到了需要輸出的蔬果信息，然后調用我們的打印函數將水果名稱打印出來。”老C說完寫下了完整的main()函數。
int main()
{
FRUIT fruit;
/* Get the information of fruit. */
fruit = GetFruitInfo();
/* Print the name of the fruit. */
PrintFruitName(fruit);
return 0;
}
“Perfect!”小P高興的說道。
“嗯，只能說不錯而已，完美還談不上。”老C點點頭，“如果我們希望添加一種新的水果到我們的系統里面，比如梨，pear，怎么辦？”
“好辦啊，我只要在FRUIT的枚舉類型中添加PEAR，然后在PrintFruitName()函數中添加一個case分支就可以了，有什么復雜的？”
“呵呵，注意你剛才用了兩個
添加的詞語，表示你有兩次添加的動作……”
“這又有什么不可以的呢？”
“沒有什么不可以，只和問題的規模有關，但是，”老C停頓一下，“這里我想強調的是語言風格的問題……”
“？”小P開始集中注意力。
“因為我們無法擺脫語言對思維方式的影響，反過來思維方式表現在代碼上就是風格，”老C指指白板，“比如這個PrintFruitName()函數，就是一個很典型的C風格函數。”
“為什么呢？”
“因為它……”老C嘆了口氣，“我不知道怎么形容，只好說的陳詞濫調一些——因為它面向過程。”老C撓撓頭，“不，確切的說它掌握了太多的細節……”
“聽不懂……”小P有些囧。
“好吧，那么讓我們來換個角度看問題。假如你現在是個測試工程師……什么叫測試工程師？就是保證代碼質量的……”老C面對一個技術幼齒有些郁悶，“他們按照一定的步驟對代碼進行測試，包括檢視代碼、使用特殊輸入數據檢驗代碼質量等等……”老C開始結巴了，“你就認為是專門檢查代碼的算了。”
“好吧，然后呢？”
“假如你剛才已經檢查過我們寫下的所有代碼，并認為它們都是正確的，這個時候有個家伙說因為需求變動需要增加PEAR到系統中，并且需要改動水果名稱的輸出格式，他剛剛更改了PrintFruitName()函數，需要你去做檢查，你會怎么辦？”
“涼拌！讓他把他改過的部分圈出來，我看他改的對不對。”
“哦，這樣會有問題的……”
“什么問題？”
“假如這個家伙是500/2，他在增加case PEAR:分支到BANANA下面的時候不小心刪除了BANANA分支的break……”
“餓滴神啊，這樣在函數輸入形參如果是BANANA，那么結果真是出人意料??！”
“是啊是啊，所以……”
“所以如果是由我檢查代碼，我可不能聽信那個家伙的話，只看他自以為修改過的部分，是吧。”小P開始有些理解了。
“是啊，你必須把今天早上做過的所有檢查再做一遍，來確保那個家伙沒有搗亂……”
“啊，那么重復的工作量豈不是很大？”小P開始覺得測試工程師個個都是雙眼通紅，走路帶晃的ggmm，“那么我們有什么好辦法呢？”
“在C語言范圍內還是有一些方法的……”老C說道，“只是都比較麻煩而已。”
“是么？讓我想想……”小P開始開動腦筋，幾分鐘后，他有些失望，“我想不出什么好方法，老C，你有什么辦法？”
“我們可以使用回調函數，或者使用指向函數的指針……”
“？”小P眼睛成星星狀，“怎么做？”
老C開始挽袖子，并在白板上涂涂抹抹。
typedef enum tagFRUIT{ORANGE, APPLE, BANANA} FRUIT;
typedef void (*PRINT_PROC)(char*);
typedef struct tagFRUIT_INFO
{
FRUIT fruit_;
const char* const name_;
}FRUIT_INFO;
void DoPrintFruitName(char* name)
{
printf("%s\n", name);
}
void DoPrintFruitNameCompany(char* name)
{
printf("XJTU's %s\n", name);
}
const FRUIT_INFO g_fruitInfo[] =
{
ORANGE, "orange"
,APPLE, "apple"
,BANANA, "banana"
};
void PrintFruitName(FRUIT fruit, PRINT_PROC printProc)
{
int i;
for (
i = 0;
i < (sizeof(g_fruitInfo)/sizeof(g_fruitInfo[0]));
++i
)
{
if (g_fruitInfo[i].fruit_ == fruit)
{
(*printProc)(g_fruitInfo[i].name_);
}
}
}
int main()
{
FRUIT fruit;
/* Get the information of fruit. */
fruit = GetFruitInfo();
/* Print the name of the fruit. */
if (/* Print fruit's company. */)
{
PrintFruitName(fruit, DoPrintFruitNameCompany);
}
else
{
PrintFruitName(fruit, DoPrintFruitName)
}
return 0;
}
“這樣，”陳老C解釋道，“如果我需要增加PEAR到系統中，只需要在g_fruitInfo的表格中增加一行就可以了。而且程序可以根據外部的需求決定是否輸輸出產水果的公司，當然這些都是說明性的，用偽代碼代替了。”
“*^*”小P看的有些眩暈，“我有些頭暈，像暈車……”
“沒有關系，只是你不熟悉罷了。”老C摸著下巴，“這就是我說的風格問題，因為思考問題的方式不同導致代碼的風格看起一時難以接受而已。”
“哦？看來只是習慣問題？那么我再看看……”克服了暈車般的頭痛，小P又看了幾遍代碼，感覺依照自己的C基礎，看懂是沒有問題的，畢竟自己還是很油菜的。“的確是習慣問題，但是為什么老C會這樣思考問題呢？”小P想。
“因為信息隱藏……”
“你怎么知道我在想什么？”
“因為你在自言自語！”老C很是囧，“我們來看看現在的代碼吧，它與我們第一版的代碼區別在于信息的隱藏和信息的外部存儲。原來的PrintFruitName()信息都存儲在函數內部，即函數需要知道具體的FRUIT枚舉才可以做出相應的輸出，而且輸出數據的格式信息也存儲在函數中。這樣這個函數就和我們的需求緊密結合，就是說如果我們的需求——水果類型和輸出名稱的信息及格式——任何一個發生變化，那么這個函數體本身也必須發生變化，代價就是——寫代碼的人和測試代碼的人都強烈拒絕新的需求變化。而如果我們把具體信息對PrintFruitName()隱藏，使得函數只知道在一個表格中尋找對應的類型，然后根據自己接口處的函數指針調用格式化輸出函數，那么在需求發生變化時，我們只需要修改具體保存信息的數據格式——比如g_fruitInfo表格，而無需修改函數體本身；更炫一點兒的是，我們還可以使用宏把對g_fruitInfo表格的操作封裝起來，防止維護人員對g_fruitInfo表格進行誤操作……但是考慮到你的承受能力，我們以后再談論這個話題。這樣，就產生了相對穩定的結構——PrintFruitName()函數體，但是此設計又沒有拒絕維護人員根據需求進行變更……”
“哦，讓我再想想……”小P又回頭去看代碼，“這次感覺好多了，但是，”小P開始惡狠狠的對老C說，“你一早就這么寫出來得了，為什么還要我浪費時間啊！”
“我又沒有說你寫得不好，如果是我第一次寫，我也會寫得和你一樣！”
“？”
“一切都由需求而定！我們一開始時并不知道哪些需求會發生變化，因此只要滿足現有需求就可以了，所以你一開始寫的代碼并沒有什么不妥……問題發生在需求變化之后，”老C加重了語氣，“現在我們已經知道需求可能在那些地方變化，而且就現實情況而言，一旦需求在某處發生變化，那么它就會經常在此處發生變化。這個時候我們就需要對程序結構進行調整，以應對這種變化，而不只是在原來的基礎上縫縫補補……那樣會帶來很多重復性的勞動！”
“……槑”
“算了，這些都是隨著編碼規模的增大而得來的經驗，相信你以后會逐步明白的，我看好你哦！”
“謝謝啊！”
“總之這就是思維的差異帶來的代碼風格的差異，我也是在用C++進行了幾次項目之后才慢慢明白的，如果只是單純的游弋在C語言的世界，我覺得我要明白這些東西還需要很長時間啊。”
“這個和C++有什么關系？”小P有些不解。
“當然有關系了，因為使用了C++后，我思考問題的方式與只使用C的時候發生了很大的不同，因為思維方式的不同，導致我的C代碼風格發生了很大變化……但是話說回來，每種風格沒有好壞的區別，只有合適不合適的區別。等我們打掃完實驗室，我們再試試怎么用C++改寫這些代碼，至于現在，時候也不早了，我們去吃午飯吧！”制止住又想發問的小P，老C拉起他就向門外走。
“哎哎，我還有問題要問呢，要不吃飯的時候你再噴噴……”
(未完待續)
(請勿轉載，謝謝！)