設計模式（Design pattern）代表了最佳的實踐，在面向對象的程式設計中被很多老鳥們反複使用。使用設計模式是有很多好處，例如：
可重用代碼
使代碼更易被他人了解
保證代碼可靠性
……
毫無疑問，設計模式于己于人于系統都是多赢的。《設計模式》之于程式員，就好比《聖經》之于耶稣信徒一樣，意義可想而知！
<a href="#%E7%AE%80%E8%BF%B0">簡述</a>
<a href="#%E4%BB%80%E4%B9%88%E6%98%AF-gof">什麼是 GoF</a>
<a href="#%E8%AE%BE%E8%AE%A1%E6%A8%A1%E5%BC%8F%E7%9A%84%E7%B1%BB%E5%9E%8B">設計模式的類型</a>
<a href="#%E5%88%9B%E5%BB%BA%E5%9E%8B%E6%A8%A1%E5%BC%8F">建立型模式</a>
<a href="#%E7%BB%93%E6%9E%84%E5%9E%8B%E6%A8%A1%E5%BC%8F">結構型模式</a>
<a href="#%E8%A1%8C%E4%B8%BA%E5%9E%8B%E6%A8%A1%E5%BC%8F">行為型模式</a>
<a href="#n-%E9%97%AE%E8%AE%BE%E8%AE%A1%E6%A8%A1%E5%BC%8F">N 問設計模式</a>
<a href="#%E6%BA%90%E7%A0%81%E5%9C%B0%E5%9D%80">源碼位址</a>
談及設計模式，必然離不開 GoF。
GoF：Gang of Four，也稱為“四人組”，即：EErich Gamma、Richard Helm、Ralph Johnson 和 John Vlissides 四人。
1994 年，這幾位大牛合著出版了一本名為《Design Patterns: Elements of Reusable Object-Oriented Software》（即：《設計模式》）的書。該書首次提到了軟體開發中設計模式的概念，将設計模式提升到理論高度，并将之規範化。書中提及了 23 種基本設計模式，時至今日，在可複用面向對象軟體的發展過程中，新的設計模式仍然不斷出現。
來認識下幾位作者：
這就是傳說中的“風塵四俠”，比起國外的其他技術大咖（不修邊幅），看起來要好很多~O(∩_∩)O~。
根據設計模式參考書《設計模式》，共有 23 種設計模式。這些模式可以分為三類：
類型
描述
建立型模式（Creational Patterns）
提供了一種在建立對象的同時隐藏建立邏輯的方式，而不是使用 new 運算符直接執行個體化對象。這使得程式在判斷針對某個給定執行個體需要建立哪些對象時更加靈活。
結構型模式（Structural Patterns）
關注類和對象的組合。繼承的概念被用來組合接口和定義組合對象獲得新功能的方式。
行為型模式（Behavioral Patterns）
特别關注類對象之間的通信
保證一個類僅有一個執行個體，并提供一個通路它的全局通路點。
提供一個建立一系列相關或互相依賴對象的接口，而無需指定它們具體的類。
将一個複雜對象的建構與它的表示分離，使得同樣的建構過程可以建立不同的表示。
定義一個用于建立對象的接口，讓子類決定将哪一個類執行個體化。Factory Method 使一個類的執行個體化延遲到其子類。
用原型執行個體指定建立對象的種類，并且通過拷貝這個原型來建立新的對象。
将一個類的接口轉換成客戶希望的另外一個接口。Adapter 模式使得原本由于接口不相容而不能一起工作的那些類可以一起工作。
橋接模式（Bridge Pattern）
将抽象部分與它的實作部分分離，使它們都可以獨立地變化。
動态地給一個對象添加一些額外的職責。就擴充功能而言，它比生成子類方式更為靈活。
将對象組合成樹形結構以表示“部分-整體”的層次結構。它使得客戶對單個對象和複合對象的使用具有一緻性。
為子系統中的一組接口提供一個一緻的界面，Facade 模式定義了一個高層接口，這個接口使得這一子系統更加容易使用。
享元模式（Flyweight Pattern）
運用共享技術有效地支援大量細粒度的對象。
代理模式（Proxy Pattern）
為其他對象提供一個代理以控制對這個對象的通路。
模版方法模式（Template Method Pattern）
定義一個操作中的算法的骨架，而将一些步驟延遲到子類中。Template Method 使得子類可以不改變一個算法的結構即可重定義該算法的某些特定步驟。
将一個請求封裝為一個對象，進而使你可用不同的請求對客戶進行參數化；對請求排隊或記錄請求日志，以及支援可取消的操作。
疊代器模式（Iterator Pattern）
提供一種方法順序通路一個聚合對象中各個元素，而又不需暴露該對象的内部表示。
定義對象間的一種一對多的依賴關系，以便當一個對象的狀态發生改變時,所有依賴于它的對象都得到通知并自動重新整理。
中介者模式（Mediator Pattern）
用一個中介對象來封裝一系列的對象互動。中介者使各對象不需要顯式地互相引用，進而使其耦合松散，而且可以獨立地改變它們之間的互動。
備忘錄模式（Memento Pattern）
在不破壞封裝性的前提下，捕獲一個對象的内部狀态，并在該對象之外儲存這個狀态。這樣以後就可将該對象恢複到儲存的狀态。
解釋器模式（Interpreter Pattern）
給定一個語言，定義它的文法的一種表示，并定義一個解釋器，該解釋器使用該表示來解釋語言中的句子。
狀态模式（State Pattern）
允許一個對象在其内部狀态改變時改變它的行為。對象看起來似乎修改了它所屬的類。
政策模式（Strategy Pattern）
定義一系列的算法,把它們一個個封裝起來, 并且使它們可互相替換。本模式使得算法的變化可獨立于使用它的客戶。
職責鍊模式 / 責任鍊模式（Chain of Responsibility Pattern）
為解除請求的發送者和接收者之間耦合，而使多個對象都有機會處理這個請求。将這些對象連成一條鍊，并沿着這條鍊傳遞該請求，直到有一個對象處理它。
通路者模式（Visitor Pattern）
表示一個作用于某對象結構中的各元素的操作。它使你可以在不改變各元素的類的前提下定義作用于這些元素的新操作。
GoF 中提出的設計模式，至今仍被人津津樂道，你了解多少呢？
沒聽過（厲害了）
聽過，不知道具體能幹嘛
了解，會用其中的兩三種
熟悉，能根據實際情況快速設計
精通，遊刃有餘（上天了）
第一種人：“雖然不懂你們在說什麼，貌似很厲害的樣子”。大牛才會用到的東西，高端而又神秘！
最後一種人：“已上天，正和太陽肩并肩”。傳說中的人劍合一，未曾想用設計模式，寫出的代碼卻處處都是。
其他情況都是正常人的範疇，當然，我也是~O(∩_∩)O~。。。是以，認真學習吧！
有些人說設計模式沒用，真是這樣嗎？
引用一句哲學名言：存在即合理。如果沒有用，那為何存在？如果要扯非 OO 語言，那也許真沒什麼用！但是，可以肯定的是，非 OO 語言完全可以借鑒 OO 的思想，設計模式也不例外！
設計模式有多重要？
要做一位大神，或所謂的高手，基本之一就是要懂得若幹設計模式。設計模式是軟體工程的基石脈絡，如同大廈的結構一樣，你說有多重要？
如何選擇設計模式？
設計模式是針對某種情景下某種問題的某種解決方案，也就是說，每個模式都有自己的意圖、使用場景、使用方法和使用後果。正所謂物有兩極，各模式也存在相應的優缺點，是以呢，得其優，而避其劣，終得之！
為什麼要寫設計模式？
雖然設計模式被很多人念叨，并不斷書寫，但筆者還是決定追随前人的腳步。我很喜歡一句話：“你會了不代表你真的會，要是你能讓别人也會，你才是正的會了”！
要真正領悟設計模式的精髓，需要有大量實踐經驗的積累，這往往是一個漫長的過程。
部落格中涉及的所有設計模式都會基于實際案例，反複打磨，并進行故事化的分解。相關源碼均在筆者的 GitHub 中可以找到，全部經過驗證。
持續更新中……