目錄概要
設計模式的開山之作
1994年10月21日，有四個哥們兒出版了一本書，名字叫做《設計模式：可複用物件導向軟體的基礎》（Design Patterns: Elements of Reusable Object-Oriented Software）。
這四個哥們兒後來以“四人幫”（Gang of Four，GoF）著稱，而他們的《設計模式：可複用物件導向軟體的基礎》一書也就成為了設計模式的開山之作。
對設計模式的誤解
筆者之前釋出了幾篇介紹設計模式的的部落格，看到有的讀者對設計模式的評論是：
- 看了也不會，會了也不用
- 設計模式有使用場景的，不能生搬硬套
- 我寫了那麼多年程式碼，從來沒用過設計模式
關於使用設計模式的3個問題
這裡我不得不說，大家對設計模式是有很多誤解的，面對設計模式我們至少要思考下面3個問題：
- 首先，什麼是設計模式？
設計模式簡而言之就是一些常見軟體設計問題的標準解決方案。
正如設計模式的開山之作《設計模式：可複用物件導向軟體的基礎》一書中所說的那樣：
- 所有結構良好的物件導向體系結構中都包含了許多設計模式。
- 設計面對向軟體比較困難，而設計
可複用的物件導向軟體就更加困難。- 內行的設計者知道：不是解決任何問題都要從頭做起。他們更願意複用以前使用過的解決方案。當找到一個好的解決方案，他們會一遍又一遍地使用。這些經驗是他們成為內行的部分原因。
可以說，如果問題是我們的敵人，程式碼是我們的劍，設計模式就是高手心中的劍譜。
- 接著，怎麼使用設計模式
《Head First 設計模式》一書的作者裡曼說，使用設計模式有3個層次：
• Beginner —— 初級選手，在程式設計的時候無處不用設計模式，認為用的模式越多設計就越好。
• Intermediate —— 中級選手，在程式設計的時候知道何時該用什麼設計模式，而什麼時候不該用。
• Zen —— 到了禪的境界，“他山之石，可以攻玉”。設計模式被用來簡化設計，讓設計更優雅。
非要把設計模式硬塞到設計之中，那只是初級菜鳥的層次。
- 最後，設計模式在實際生產中使用的多不多？
設計模式本身就是源自實際問題的優秀解決方案的總結，因此在很多基礎的架構和框架裡，都可以看到設計模式的影子。
比如Java開發者經常使用的Spring框架，從建立型的工廠模式、單例模式、原型模式，再到結構型的享元模式、代理模式，再到行為型的觀察者模式、模板模式，在其原始碼中隨處可見。
無處不在的設計模式
設計模式不是空中樓閣，也不是隻有面試和吹牛的時候才能放在嘴邊的炫耀資本，而是一個優秀的開發者可以讓自己的設計更加優雅的不可或缺的好幫手。
並且設計模式也並不是軟體行業特有的現象，很多行業中有經驗的從業者都會使用各種“模式”來優化自己的設計。
就拿劇本創作舉例，如果一個劇作家要寫一個劇本，並不是完全憑空建立的，也有各種業內普遍應用的模式，例如“悲劇英雄模式”(《麥克白》、《哈姆雷特》)、“悽美愛情模式”(《羅密歐與朱麗葉》、《梁山伯與祝英臺》)等等，都是劇作家可以使用的“設計模式”。
如何解釋設計模式
一般而言，要介紹一個設計模式，至少要包含如下4個要素：
- 問題(Problem)
描述了我們遇到了哪些問題，也就是某個設計模式的使用場景。
- 解決方案(Solution)
為了解決上面遇到的問題，我們想到了哪些解決方案。其中最具有普遍性的方案往往就是我們的設計模式的內容。
- 效果(Consequence)
設計模式就像一個模板，可以為解決不同的問題提供思路。而解決問題的效果就是衡量一個設計模式在某個場景下是否適合的關鍵因素，一般我們要衡量的方面有靈活性、可移植性、可擴充性、效能等。
- 模式名稱(Pattern Name)
一個好的名字，可以讓我們記住某個模式，並且可以望名知意，使其更便於傳播。甚至作為我們思維方式的一部分保留下來。
以上面4個要素為基礎，我們解釋設計模式可以分為如下幾個方面：
- 模式名稱：模式的名字
- 模式別名：模式的其他名字或者暱稱
- 模式分類：模式屬於那種型別
- 模式意圖：回答模式是幹什麼的，為了解決什麼問題等問題
- 模式結構：模式包含哪些角色，以及這些角色之間的關係
- 模式適用性：哪些場景適合使用該模式
- 模式實現：通過例子來展示模式的實現過程
- 已知應用：該模式已經被使用在了什麼地方
- 相關模式：模式中用到的模式，與該模式有替代關係的模式
釋出/訂閱模式 和 事件驅動模型 從原理到實戰的系列文章：
- 設計模式之釋出訂閱模式(1) 一文搞懂釋出訂閱模式
- 設計模式之釋出訂閱模式(2) Redis 釋出/訂閱模式
- 設計模式之釋出訂閱模式(3) 深入Spring Events事件驅動模型
- 設計模式之釋出訂閱模式(4) Guava Eventbus 事件處理