本文將簡單的介紹一下我讀《設計模式》（GOF95）這本書的經驗和教訓。

我想首先應該講的是，這本書應該怎么讀。

幾乎沒什么程序設計經驗的新手，重點讀第一章，第二章，明白一些大概的原則；
有一定的程序設計經驗的人，讀自己熟悉的模式，以及一些簡單的、易于理解的模式，注意區別自己以前在遇到類似問題的時候是怎么解決的，GOF是怎么解決的，為什么；不需要太過于區分一些接近的模式，順其自然就好。
對于如果你能熟練的編碼，并開始擁有自己的設計思路的人，重點在學習用GOF的方式描述自己的經驗，尋找自身思路和GOF的思路的差異性，熟悉一些自己沒太用過的模式。
如果是已經閱讀過設計模式，并且已經有了一些運用經驗的人，詳細讀第一章，第二章，以及每一大類的模式的總結和每個模式的最后一節，注意區分模式之間的差異性以便于在系統中準確的選擇。

接下來我希望能和大家討論一下我對于設計模式的核心動機的理解，歡迎大家回帖的時候各抒己見，我會將大家的意見整理出來，并放在帖子中～

首先討論一下構造型模式。

Factory Method
描述：
是最基本的構造型模式。它將構造從單純的構造函數中分離出來。
動機：
用于封裝復雜的或者是易于變化的構造操作。
適用性/作用：
適用于創建那些構造時需要初始化的對象，或者需要按一定次序構造對象的時候。該模式結構很簡單，額外的代碼量也很少，因此適合在開發的開始階段就可以使用，它通常不會有那些“過度設計”的麻煩。它的另外一個實際作用，是可以統一程序的對象構造風格，增強可讀性。

Abstract Factory
適用性/作用：
維護一個對象系列的一致性。當存在多個并行繼承體系，并且每一組繼承都較為獨立，且容易錯誤的混用時候，建議使用該模式來構造對象系列。

Builder
適用性/作用：
當對象構造步驟復雜，并且每個步驟都使用同樣的接口，但是它們具備不同實現的時候，可以選擇該模式。常用于創建 構造邏輯接近、但其構造實現差異很大 的一系列對象，如構造不同格式的文本文檔（GOF的示例），它們的構造邏輯接近，但是實現卻是與平臺相關的。

Prototype
適用性/作用：
這個模式的本意是從一個對象構造另外一個對象。在一個應用系統中，由于我們通常也能很方面的使用其它的構造方法；或者我們只需要一個按照默認初始化方式構造的對象，這樣并不適合使用原型。當我們希望從不是由客戶代碼控制的對象中復制出一個相同的但是被客戶代碼管理的對象（管理權移交）；或者是對象需要深拷貝語義；或者是兩個子系統協作時，一個系統無法方便的訪問到另外一個系統的構造函數，但是確能很方面的獲得它的實例時（往往是由參數傳遞進來的），便需要使用這樣一個模式存在。

Singleton
適用性/作用：
提供一個全局唯一的描述。還可以用來取代一些難以避免的全局變量。

有關于構造型的一些個人看法：
在C++中，由于構造函數不能多態調用虛成員函數，因此很多時候Factory Method成為了維持構造-初始化的一致性的逼不得已的選擇；但是在C#一類的語言中，由于構造函數本身是虛函數，因此一些Factory Method的作用可以通過將Template Method運用到構造函數中來避免一部分Factory Method的使用；Factory Method更加強調于封裝可能的構造方法變化，以及統一設計風格，而不是隱藏不必要的構造步驟。

然后是結構型模式：

Adapter
描述：
轉換接口的格式（也可以說轉換接口的signature）。
適用性/作用：
通常是為了統一程序風格。例如在開發系統時，發現某一個系統所使用的程序庫接口不符合系統約定，便需要使用Adapter模式適配接口，使風格統一。該模式也可用于使兩個系統接合到一起工作。

Bridge
描述：
分離接口與實現。
適用性/作用：
Bridge的Interface與其Implementation通常在程序的架構中是垂直關系，即上層調用下層。在基礎設置，即Impl發生變化的時候，可以避免使用Interface的客戶代碼發生變化。將實現部分的變化消滅在接口上。
在一些使用beta版的lib開發軟件，或者是開發所依賴的庫有較大的可能性在軟件的生命期內發生改變時，通常回使用該模式。

Composite
適用性/作用：
描述嵌套的結構，類似于程序設計里的遞歸，當每一個對象既是一個有獨立功能的對象，也是一個容器時，通常會選擇該模式，典型的例子就是XML Document。每一個節點都可能包含了葉節點。
需要注意的是，這些被包容和對象，和容器都具有及其類似的邏輯；如果從接口的層面上，可以認為這些對象是自包含的。