“我們來看看
PrintFruitName()函數的問題，它的一個比較明顯的缺陷是效率。”老C用筆指著代碼說道。
“是啊是啊，”有機會表現一把小P很是高興，“這個函數做了線性查找，因此它的時間效率應當是n。”
“對，因此對比原版的switch...case...語句的常數時間效率，我們現在的設計在時間效率上有損失，你有什么好辦法解決這個問題嗎？”
“讓我想想……”小P又開始發動腦筋，“我覺得我們可以使用一個散列表來儲存這些信息，那么在查找的時候算法的時間復雜度就是常數了。”小P找到了解決辦法很是高興，就想著去白板上寫下自己的得意之作。
“等等別急。”老C攔住小P，“只要知道了解決之道，代碼是微不足道的，你先不要著急寫代碼……”老C對小P的反應速度有些驚訝，“我覺得你的基礎挺好的啊，就是缺乏正確的引導……”
“呵呵，謝謝啊，其實我就是比較油菜而已。”聽了老C的評論小P有些囧，不知道他是表揚還是批評。
“我們不著急對這一版進行改寫，現在你試著使用C++來完成上面的代碼。”老C給小P出了新的題目。
“嗯，我看看啊。”小P開始思索起來，“但是有什么不同嗎？如果使用C++的話，我可能還是會寫出第一版那樣的代碼啊……”
“所以我說你缺乏正確的引導啊，”老C有些感慨，“因為C++包含了C的部分，因此你完全可以用C的思維方式在C++下編碼，反應到代碼風格上，就是第一版風格的代碼在C++代碼中頻繁出現……”
“槑，”小P有些莫名其妙，“那么應該怎么做呢？”
“嗯，我先簡單的寫寫，然后我們來review。”老C在白板上劃了一道線，將白板分為兩部分，在原來的代碼部分上面寫下C，然后在另一個空白部分的頭部寫下C++。
class Fruit
{
public:
virtual ~Fruit() {}
public:
virtual void printName() = 0;
}
class Orange : public Fruit
{
public:
virtual void printName() { cout << "orange" << endl;}
}
class Apple : public Fruit
{
public:
virtual void printName() { cout << "apple" << endl; }
}
class Banana : public Fruit
{
public:
virtual void printName() { cout << "bnana" << endl; }
}
void PrintFruitName(const Fruit& fruit)
{
fruit.printName();
}
int main()
{
/* Fruit factory function. */
Fruit* fruit = GetFruit();
PrintFruitName(*fruit);
delete fruit;
return 0;
}
“唔，”老C揉揉手，“差不多就是這樣啦，一個很簡單的實現……與現實代碼相去甚遠……”他又想了想，“在實際情況下我們是不會這樣編碼的，但在這里只是說明一下思維的差異性。”
“給我講講吧。”小P等待下文。
“在這個實現里我們使用了C++的多態特性，也有一種說法是晚綁定……但是無論怎么說，其根源也是信息隱藏。”老C開始比較C和C++的實現，“我們已經比較過第一版和第二版的C實現，發現信息隱藏是進行設計的一個關鍵點……”
“等等老C，什么叫多態？什么叫晚綁定？”
“哦，我們來看看PrintFruitName()函數，你能說清楚這個函數具體實現了哪些需求？”如何簡單的解釋這些術語讓老C覺得有些頭痛。
“從代碼看它實現了對fruit對象名稱的打印……”小P看了看代碼，“但是具體如何做的我看不出來，而且打印的內容與函數的輸入參數有關，不同的參數會有不同的結果……”
“沒錯！保持統一的接口，而具體行為依照對象而定，不同的對象有不同的行為，這個就是對多態的簡單解釋。”老C覺得小P還是有些悟性的，“具體在C++語
言中，多態通過指針和引用來表現。即接口使用父類的指針或引用來表明抽象的統一的接口，而行為根據父類指針或引用所指向具體子類對象，不同的對象表現出不
同的行為，此乃C++實現多態的風格，具體來說我們在編程的時候需要使用指向父類的指針或者引用，然后在子類中改寫父類中的虛函數，最后再把子類對象賦值
到父類指針或引用上。如果現在我們需要再增加一個梨這樣的水果，你會怎么做？”
“好像很簡單了？”小P試著在白板上寫下如下代碼。
class Pear : public Fruit
{
public:
virtual void printName() { cout << "pear" << endl; }
}
"然后怎么辦？我可能還需要改寫GetFruit()函數，使得他可以增加一個返回的對象類型？"小P很細心的發現一個問題，“但是我覺得我們很難在
GetFruit()函數中避免類似if..else...或者switch...case..之類的邏輯選擇分支……等等，好像我們實現的第二版C語言
代碼也存在類似的問題，就是GetFruitInfo()中也無法避免多選擇的判斷分支……”
"沒有錯！但是起碼我們對PrintFruitName()函數的維護會好很多。"老C很是贊同小P的觀察力，“這個是另外的問題，涉及到一些
factory模式，我們以后再討論……無論怎么樣，我們先來評判一下現在C++的實現。因為C++的虛函數實際上采用散列表的數據結構實現，所以我們的
C++程序執行效率會比白板另一邊的第二版C代碼好一些。我覺得我以后一定會和你討論一下C++的虛函數的實現的，但是今天我們先把這個問題放一邊。”
“看來C++還有很多東西是我不了解的啊。”小P開始覺得自己C++課程好像是白上了。
“我們來比較一下三個版本的實現。”老C開始回顧早上的討論，“你發現什么問題沒有？”
“好像一段代碼對其具體實現了解的越少，它的維護性就會越好？”小P有些猜測。
“呵呵，的確，那么我們通過各種不同的方法達到了什么樣的看似相同的目的？”老C開始掉小P的胃口。
“信息隱藏？”小P不太確定。
“信息隱藏是手段，但不是目的。”老C很確定的否決掉小P，“我們達到的目的是
控制問題的規模！”
老C覺得有必要給小P講講哲學：“我們寫軟件的目的是為了解決現實生活中的具體問題，沒錯吧？”
“沒錯，的確是這樣，可是這個和C++有什么關系的？”小P覺得有些莫名其妙。
“那么你覺得使用高級的語言、先進的設計和合理的開發流程，問題的復雜度會降低嗎？”
“那是啊，問題的復雜度當然會降低啊。”
“唉，錯了，問題的復雜度不會降低的，因為問題的復雜度是客觀存在，不會因為人主觀的原因而改變！”
“槑！”小P有些被震住了，他以前還真是沒有考慮過這樣的問題，“那么為什么我覺得C解決問題比匯編簡單呢？”
“那是因為問題的規模被控制了！”老C開始強調，“因為C的編連器暗地里幫你做了很多事情來控制問題表現給你的規模，使你感覺好像問題變簡單了——其實是你面對的問題規模變小了。打個比方，”老C在白板上找出了上午最早的程序。
typedef enum tagFRUIT{ORANGE, APPLE, BANANA} FRUIT;
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;
}
}
int main()
{
FRUIT fruit;
/* Get the information of fruit. */
fruit = GetFruitInfo();
/* Print the name of the fruit. */
PrintFruitName(fruit);
return 0;
}
“看看吧，根據你剛才的發現，是不是如果需求發生變化時，GetFruitInfo()和PrintFruitName()這兩個函數都要發生變更？”老C指著代碼問小P。
“是啊，沒有錯。”
“現在我們代碼的規模還很小，如果我們在多處需要涉及到水果的信息，那么根據這種風格，如果需求發生變更時，是不是每個地方都需要對源代碼進行修改？”老C開始循循善誘。
“嗯，好像是的。我們這里只是打印了水果的名稱，如果我們還需要水果的形狀，水果的顏色，哦，好像我們維護時候的復雜度會按照問題的規模成倍的增長。”
“是啊是啊，這就叫牽一發而動全身。”老C總結道，“那么第二個做法呢？”
“好像可以好一些，起碼我們只用修改某些表格，哦，還要修改哪個GetFruitInfo()的函數，但是起碼問題的擴散沒有那么嚴重了……”小P現在隱約覺得自己好像腦袋里面有只手，快要抓住什么東西卻又抓不到，有些迷蒙起來。
“但是維護表格的工作量也不小啊。”老C補充道，“那么最后一種做法呢？”
“我個人感覺好像C++編連器在幫助我們維護這些表格？”小P好像猛的明白過來，“比如將虛函數的實現隱藏在編連器的后面……”他又開始有些迷蒙……
“是的，是這樣的。”老C點點頭，“我們實際上面對問題的復雜度并沒有改變，只是由于語言的幫助，我們可以設計出一些代碼來限制我們接觸問題的規模，把一
個復雜的問題逐步劃分到我們自己可以理解的規模上來，這樣好像問題變簡單了一樣。”老C接著說道，“這就是我為什么說我們所使用的語言會影響到我們思考問
題的方法，而我們思考問題的方法會反過來影響我們編碼的風格。”
小P突然感覺自己來到了一個更寬闊的世界，好像自己突然明白了什么又好像不是很明白……小P開始覺得C++充滿了神秘和樂趣，下決心一定要把C++學好。
“老C，和你聊聊太有收獲了，我要把這些代碼抄下來回去再看看，體會體會，”小P做激昂狀，“我一定要在3年內學好C++……”
“等等，3年時間好像太短了吧？”老C有些被雷到了。
“？”
“建議你看看《Teach Yourself Programming in Ten Years》這篇文章吧，急是急不來的。”老C覺得年輕人就是浮躁。
“哦？好，那我回宿舍后查查這篇文章。但是以后你要多教教我啊。”
“互相討論，互相學習。”老C謙虛道，“C++還有template種類的編程風格，但是我想我們還是討論到此吧，時間也不早了，我們回去吧。”
“好啊，回去打一盤魔獸，看看誰更厲害！”小P決定也給老C當一回老師過過癮！
(欲知后事如何，且聽下回分解)