編程成長之路何嘗不是這樣的呢？

故事就是從這里開始的。

小王是剛畢業的學生，進入一家軟件公司，薪水不錯。年輕人充滿干勁，有著遠大的目標。前三天參加了公司的培訓，三天沒寫代碼了，手癢。第四天，項目經理走過來說：“小王，寫一個整型鏈表的排序算法吧，我們在項目中要用。”

冒泡是小王在腦海中第一個浮現出來的。翻開某某圣經，摘了段冒泡算法，修改了一些代碼的書寫風格（有些圣經代碼風格不咱的），代碼大致如此：

bool sort(listint)

{

冒泡排序算法

{

比較語句

}

return true；

}

小王檢查了一下，還用測試用例測試了一把，確保萬無一失，交給了經理。經理說了句不錯，樂壞了小王。

第二天，經理跑過來說：“把你昨天的代碼改一下，現在要比較浮點型了，還有能否速度上提高一點？”

小王上網查了一下，選擇了快速排序算法，不忘把昨天寫的備份了一把，然后在昨天函數的基礎上改。代碼大致如此：

bool sort(listint)

{

快速排序算法

{

比較語句

}

return true；

}

easy嗎？測試交差。

一年后……

鏡頭切換……

小王坐在計算機前熟練的編寫著程序，而且旁邊還放著本《設計模式》的書。知道了面向對象編程，知道了設計模式，但理解還不夠深刻。排序算法也演變成比較文件名了。

一日經理過來說：“小王，現在我們的排序算法要用在嵌入式平臺中，你做一些算法的研究工作，給出一份報告。”

這不是策略模式的典型應用嗎？定義一系列的算法，把它們一個個封裝起來，并且使他們可以相互轉換。

小王畫了張uml圖：

這樣，小王把一些流行的排序算法都試了一遍，總共有七八種，換一種算法速度也很快，新的算法插入到系統中，老算法從系統中"退休"，實現插件式替換。

csort *psort ＝ new cbubblesort;

cclient.listsort(psort);

如果要改成快速排序，只要如此：

csort *psort ＝ new cquicksort;

cclient.listsort(psort);

測試交差，當然經理自己也有想法，又讓小王試了另外的幾個算法，小王都能輕松的完成。策略模式的作用在這里淋漓盡致的發揮了，小王心里特別有成就感。

過了些日子，客戶提出需要按文件名、日期進行排序，小王覺得這還是比較簡單的，更改了一下uml圖：

改代碼的主要工作是copy-paste，就四個函數，也就很快完成了。

客戶的需求是不會停止的，為了加強功能，提出需要按文件大小、文件的類型排序，天知道客戶還會提出什么要求。

“再也不能這樣活”，小王聽著歌，陷入了沉思。

“排序的算法和比較算法分開來會如何呢？把它們脫耦，使得二者可以獨立地變化。這句話怎么這么熟悉，我肯定在哪里看到過。”小王忙翻開《設計模式》，開始查閱。

“got it，這不就是橋梁模式（bridge）。”一陣欣喜，馬上就干。半個小時后，uml圖出來了，如下：

客戶端代碼如下：

csort *psort = new cquicksort;

ccomparetype *ptype = new cnamecompare;

psort->settype(ptype);

psort->sort(plist);

哈哈，客戶們，你們盡管提要求吧。