序

這篇《設計模式之路》是看完四人幫的《design pattern》之後的感悟。《設計模式》重劍無鋒，大巧不工。即使有很好的程式設計基礎，很高的英語閱讀水平，也未必能窺知全貌。筆者試圖將《設計模式》演繹為通俗易懂的白話，簡單生動的故事。在閒暇時光，重溫舊知，也是一件愜意的事情。

為什麼取名為on road？是因為筆者一直在探求知識的路上，而這條路永無終止！

順便說一句，想不看《設計模式》，直接看了本文就想弄懂什麼是設計模式的，有點兒不切實際。本文源於經典，不能超越經典，必須有點兒基礎再來看看。

另外，《設計模式》這本書也需要懂一些UML的知識，如果沒有的話，請在百度或者谷歌一些UML的基本知識，至少需要知道什麼是依賴、繼承、組合、聚合之類的概念。

起

《設計模式》這本書起源於一個文字編輯器的開發案例。我相信這四個老賊選取這個案例要麼是他們在開發過程中真正的痛苦過；要麼就是非常雞賊的，有遠見的，刻意的選取。我相信前者的原因居多。科學來源於實踐，能在開篇中就將lexi編輯器舉出例項，且映射了8個設計模式的案例一一列舉。沒有經歷過（這個編輯器的開發過程），讓人很難相信。

一個文字編輯器，設計的8中設計模式如下：

組合模式

策略模式

修飾器模式

抽象工廠模式

工廠模式

橋接模式

命令模式

迭代器模式

• 組合模式
  

組合模式在Lexi編輯器這個case中出場的情形最普通。就是設計者（使用者、開發者，隨便怎麼稱呼吧）需要對編輯器中的字元、文字、圖片、行、列等“物件”，進行統一的處理，不希望這些“散亂”的物件有不同的行為和屬性。就設計了一個名字叫做Glyph的抽象類，這些“物件”就被例項化自Glyph類的子類。

這裡不討論為什麼統一了行為就是合理的（本人從來相信“有錢難買我喜歡”，但要證明這個統一行為的合理性，要浪費我不少字，我一向又懶得寫字），姑且我們認為“存在即合理”或“四個老傢伙”“喜歡這樣的統一性”。簡單說下組合模式的使用特性：

1. 要組合的類，必須具有統一的行為介面，比如上文的字元、文字，都有size，都能自我draw（渲染），都能知道自己在文件中的位置（postion）。

2. 要組合的類，必須能夠遞迴組合，即一個Glyph必須能包含若干個子Glyph類得物件，而且一個Glyph可以有一個父類Glyph物件。

3. 要組合的類，根據第3點，能夠像一棵樹一樣，從不同的node之間進行物件的遊歷（注意，我說遊歷，這裡不使用“遍歷”，為的是和迭代器模式區分開）。遊歷的方式包括“父類.getChildren()”和“子類.getParent()”之類的明顯的表示方法。

組合模式，要區分於UML中的類或物件之間的“組合”關係。UML中的“組合”的關係，是描述兩個類之間的關係的，而組合模式是描述具有上述三點特徵的一組類之間的“組合”或者“聚合”的關係的。

[2012-07-11 to be continued...]