成長的煩惱：初涉設計模式

設計 　　相信很多人都喜歡看這部喜劇，我是很喜歡，裡麵包括了成長中的悲歡離合，你在其中可以尋找你成長的足跡。

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

故事就是從這裡開始的。

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

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

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);

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