申明：文章內容整理自《設計模式：可復用面向對象軟件的基礎》、第二幅插圖來自極客時間《設計模式之美》。
如有謬誤，還望指正！

文章目錄

• 設計模式的編目與分類
• • 1. 設計模式的編目
  • 2. 設計模式的分類
• 怎樣選擇設計模式
• 怎樣使用設計模式

---

設計模式的編目與分類

1. 設計模式的編目

共包含23個設計模式。它們的名字和意圖列舉如下，以使讀者有個基本了解。

• Abstract Factory: 提供一個創建一系列相關或相互依賴對象的接口，而無須指定它們具體的類。
• Adapter: 將一個類的接口轉換成客戶希望的另外一個接口。 Adapter模式使得原本由于接口不兼容而不能一起工作的那些類可以一起工作。
• Bridge:將抽象部分與它的實現部分分離，使它們都可以獨立地變化。
• Builder:將一個復雜對象的構建與它的示分離，使得同樣的構建過程可以創建不同的表示。
• Chain of Responsibility:解除請求的發送者和接收者之間的耦合，使多個對象都有機會處理這個請求。將這些對象連成一條鏈，并沿著這條鏈傳遞該請求，直到有一個對象處理它。
• Command:將一個請求封裝為一個對象，從而使你可用不同的請求對客戶進行參數化；對請求排隊或記錄請求日志，以及支持可取消的操作
• Composite:將對象組合成樹形結構以表示“分-整體”的層次結構. Composite使得客戶對單個對象和組合對象的使用具有一致性。
• Decorator:動態地給一個對象添加一些額外職責。就擴展功能而言， Decorator模式比生成子類方式更為靈活。
• Facade:為子系統中的一組接口提供一個一致的界面， Facade模式定義了一個高層接口，這個接口使得這一子系統更加容易使用。
• Factory Method:定義一個用于創建對象的接口，讓子類決定將哪一個類實例化。 Factory Method使一個類的實例化延遲到其子類。
• Flyweight:運用共享技術有效地支持大量細粒度的對象。
• Interpreter:給定一個語言，定義它的文法的一種表示，并定義一個解釋器，該解釋器使用該表示來解釋語言中的句子。
• Iterator:提供一種方法順序訪問一個聚合對象中的各個元素，而又不需要暴露該對象的內部表示。
• Mediator:用一個中介對象來封裝一系列的對象交互。中介者使各對象不需要顯式地相互引用，從而使其耦合松散，而且可以獨立地改變它們之間的交互。
• Memento:在不破壞封裝性的前提下，捕獲個對象的內部狀態，并在該對象之外保存這個狀態。這樣以后就可將該對象恢復到保存的狀態。
• Observer:定義對象間的一種一對多的依賴關系，以便當一個對象的狀態發生改變時，所有依賴于它的對象都得到通知并自動刷新。
• Prototype:用原型實例指定創建對象的種類，并且通過拷貝這個原型來創建新的對象。roy4.7):為其他對象提供一個代理以控制對這個對象的訪問。
• Singleton:保證一個類僅有一個實例，并提供一個訪問它的全局訪問點。
• State:允許一個對象在其內部狀態改變時改變它的行為。對象看起來似乎修改了它所屬的類。
• Strategy:定義一系列的算法，把它們一個個封裝起來，并且使它們可相互替換本模式使得算法的變化可獨立于使用它的客戶。
• Template Method:定義一個操作中的算法的骨架，而將一些步驟延遲到子類中.Template Method使得子類不改變一個算法的結構即可定義該算法的某些特定步驟。
• Visitor:表示一個作用于某對象結構中的各元素的操作。它使你可以在不改變各素的類的前提下定義作用于這些元素的新操作。

2. 設計模式的分類

第二幅圖片來源于極客時間-設計模式之美

---

怎樣選擇設計模式

在GOF一書中，有20多個設計模式可供選擇，要從中找出一個針對特定設計問題的模式可能還是很困難的，尤其是當面對一組新模式，你還不怎么熟悉它的時候。
這里給出幾個不同的方法，以幫助你發現適合你手頭問題的設計模式：

• 考慮設計模式是怎樣解決設計問題的
  設計模式怎樣幫助你找到合適的對象、決定對象的粒度、指定對象接口以及設計模式解決設計問題的幾個其他方法。會有助于你找到合適的模式。
• 明確需要解決的問題
  首先必須要明確知道自己的軟件中存在什么樣的問題。如果問題不夠明確，是無法選擇出合適的設計模式的。
  比如，如果當前面臨的問題非常明確，就是"對象太多，太浪費內存"，那么我們就會知道"也許Flyweight"比較合適。因為Flyweight模式是通過共享對象來減少內存使用量的模式。 在學習設計模式時，我們要注意設計模式“可以解決什么問題”
• 瀏覽模式的意圖部分
  在GOF書-1.4節列出了目錄中所模式的意圖( Intent)部分。通讀每個模式的意圖，找出和你的問題相關的一個或多個模式。你可以下表所顯示的分類方法縮小你的搜查范圍。

創建型結構型行為型

類	Factory Method	Adapter(類)	Interpreter Template Method
對象	Abstract Factory Builder Prototype Singleton	Adaptor(對象) Bridge Composite Decorator Facade Flyweight Proxy	Chain of Responsibility Command Iterator Mediator Memento Observer State Strategy Visitor

---

怎樣使用設計模式

一旦選擇了一個設計模式，該怎么使用它呢? 這里給出一個有效應用設計模式的循序漸進的方法。

大致瀏覽一遍模式
特別注意其適用性部分和效果部分，確定它適合你的問題。

回頭研究結構部分、參與者部分和協作部分
確保你理解這個模式的類和對象以及它們是怎樣關聯的。

看代碼示例部分，看看這個模式代碼形式的具體例子
研究代碼將有助于你實現模式。

選擇模式參與者的名字，使它們在應用上下文中有意義
設計模式參與者的名字通常過于抽象而不會直接出現在應用中。然而，將參與者的名字和應用中出現的名字合并起來是很有用的。這會幫助你在實現中更顯式地體現出模式來。例如，如果你在文本組合算法中使用了Strategy模式， 那么你可能有名為Simple Layout Strategy或TeX Layout Strategy這樣的類。

定義類
聲明它們的接口，建立它們的繼承關系，定義代表數據和對象引用的實例變量。識別模式會影響到你的應用中存在的類，并做出相應的修改。

定義模式中專用于應用的操作名稱
這里再一次體現出名字一般依賴于應用。使用與每一個操作相關聯的責任和協作作為指導。還有，你的名字約定要一致。例如，可以使用“Create-”前綴統一標記Factory方法。

實現執行模式中責任和協作
的操作實現部分提供線索指導你進行實現。代碼示例部分的例子也能提供幫助。
這些只對你一開始使用模式起指導作用，以后你會有自己的設計模式使用方法。

關于設計模式，如果不提一下它們的使用限制，那么關于怎樣使用它們的討論就是不完整的。設計模式不能夠隨意使用。 通常你通過引入額外的間接層次獲得靈活性和可變性的同時，也使設計變得更復雜和/或犧牲了一定的性能。一個設計模式只有當它提供的靈活性是真正需要的時候，才有必要使用。 當衡量一個模式的得失時，它的效果部分是最能提供幫助的。

總結

以上是生活随笔為你收集整理的设计模式大纲整理——编目、分类、选择与使用的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。