一、設計模式的由來
設計模式從何而來
在介紹設計模式的起源之前，我們先要了解一下模式的誕生與發展。與很多軟件工程技術一樣，模式起源於建築領域，畢竟與只有幾十年歷史的軟件工程相比，已經擁有幾千年沉澱的建築工程有太多值得學習和借鑑的地方。
那麼模式是如何誕生的？讓我們先來認識一個人——Christopher Alexander（克里斯托弗.亞歷山大）博士。Christopher Alexander博士及其研究團隊用了約20年的時間，對住宅和周邊環境進行了大量的調查研究和資料收集工作，發現人們對舒適住宅和城市環境存在一些共同的認同規律，Christopher Alexander在著作A Pattern Language: Towns, Buildings, Construction中把這些認同規律歸納爲253個模式，對每一個模式(Pattern)都從Context（前提條件）、Theme或Problem（目標問題）、 Solution（解決方案）三個方面進行了描述，並給出了從用戶需求分析到建築環境結構設計直至經典實例的過程模型。
在Christopher Alexander的另一部經典著作《建築的永恆之道》中，他給出了關於模式的定義：
每個模式都描述了一個在我們的環境中不斷出現的問題，然後描述了該問題的解決方案的核心，通過這種方式，我們可以無數次地重用那些已有的成功的解決方案，無須再重複相同的工作。這個定義可以簡單地用一句話表示：
模式是在特定環境下人們解決某類重複出現問題的一套成功或有效的解決方案。【A pattern is a successful or efficient solution to a recurring problem within a context】
軟件工程中的設計模式
1990年，軟件工程界開始關注ChristopherAlexander等在這一住宅、公共建築與城市規劃領域的重大突破。最早將模式的思想引入軟件工程方法學的是1991-1992年以“四人組(Gang of Four，簡稱GoF，分別是Erich Gamma, Richard Helm, Ralph Johnson和John Vlissides)”自稱的四位著名軟件工程學者，他們在1994年歸納發表了23種在軟件開發中使用頻率較高的設計模式，旨在用模式來統一溝通面向對象方法在分析、設計和實現間的鴻溝。+
GoF將模式的概念引入軟件工程領域，這標誌着軟件模式的誕生。軟件模式(Software Patterns)是將模式的一般概念應用於軟件開發領域，即軟件開發的總體指導思路或參照樣板。軟件模式並非僅限於設計模式，還包括架構模式、分析模式和過程模式等，實際上，在軟件開發生命週期的每一個階段都存在着一些被認同的模式。
軟件模式是在軟件開發中某些可重現問題的一些有效解決方法，軟件模式的基礎結構主要由四部分構成，包括問題描述【待解決的問題是什麼】、前提條件【在何種環境或約束條件下使用】、解法【如何解決】和效果【有哪些優缺點】
軟件模式與具體的應用領域無關，也就是說無論你從事的是移動應用開發、桌面應用開發、Web應用開發還是嵌入式軟件的開發，都可以使用軟件模式。
在軟件模式中，設計模式是研究最爲深入的分支，設計模式用於在特定的條件下爲一些重複出現的軟件設計問題提供合理的、有效的解決方案，它融合了衆多專家的設計經驗，已經在成千上萬的軟件中得以應用。 1995年， GoF將收集和整理好的23種設計模式彙編成Design Patterns: Elements of Reusable Object-Oriented Software【《設計模式：可複用面向對象軟件的基礎》】一書，該書的出版也標誌着設計模式正式成爲面向對象(Object Oriented)軟件工程的一個重要研究分支。
二、設計模式是什麼（what）
設計模式的一般定義如下： 設計模式(Design Pattern)是一套被反覆使用、多數人知曉的、經過分類編目的、代碼設計經驗的總結，使用設計模式是爲了可重用代碼、讓代碼更容易被他人理解並且保證代碼可靠性。
狹義的設計模式是指GoF在《設計模式：可複用面向對象軟件的基礎》一書中所介紹的23種經典設計模式，不過設計模式並不僅僅只有這23種，隨着軟件開發技術的發展，越來越多的新模式不斷誕生並得以應用。
設計模式一般包含模式名稱、問題、目的、解決方案、效果等組成要素，其中關鍵要素是模式名稱、問題、解決方案和效果。模式名稱(Pattern Name)通過一兩個詞來描述模式的問題、解決方案和效果，以便更好地理解模式並方便開發人員之間的交流，絕大多數模式都是根據其功能或模式結構來命名的；問題(Problem)描述了應該在何時使用模式，它包含了設計中存在的問題以及問題存在的原因；解決方案(Solution)描述了一個設計模式的組成成分，以及這些組成成分之間的相互關係，各自的職責和協作方式，通常解決方案通過UML類圖和核心代碼來進行描述；效果(Consequences)描述了模式的優缺點以及在使用模式時應權衡的問題。
雖然GoF設計模式只有23個，但是它們各具特色，每個模式都爲某一個可重複的設計問題提供了一套解決方案。根據它們的用途，設計模式可分爲創建型(Creational)，結構型(Structural)和行爲型(Behavioral)三種，其中創建型模式主要用於描述如何創建對象，結構型模式主要用於描述如何實現類或對象的組合，行爲型模式主要用於描述類或對象怎樣交互以及怎樣分配職責，在GoF 23種設計模式中包含5種創建型設計模式、7種結構型設計模式和11種行爲型設計模式。此外，根據某個模式主要是用於處理類之間的關係還是對象之間的關係，設計模式還可以分爲類模式和對象模式。我們經常將兩種分類方式結合使用，如單例模式是對象創建型模式，模板方法模式是類行爲型模式。+
值得一提的是，有一個設計模式雖然不屬於GoF 23種設計模式，但一般在介紹設計模式時都會對它進行說明，它就是簡單工廠模式，也許是太“簡單”了，GoF並沒有把它寫到那本經典著作中，不過現在大部分的設計模式書籍都會對它進行專門的介紹。
常用設計模式一覽表
| 類型 | 模式名稱 | 學習難度 | 使用頻率 |
|---|---|---|---|
| 創建型模式 Creational Pattern | 單例模式 Singleton Pattern | ★☆☆☆☆ | ★★★★☆ |
| 創建型模式 | 簡單工廠模式 Simple Factory Pattern | ★★☆☆☆ | ★★★★☆ |
| 創建型模式 | 工廠方法模式 Factory Method Pattern | ★★☆☆☆ | ★★★★★ |
| 創建型模式 | 抽象工廠模式 Abstract Factory Pattern | ★★★★☆ | ★★★★★ |
| 創建型模式 | 原型模式 Prototype Pattern | ★★★☆☆ | ★★★☆☆ |
| 創建型模式 | 建造者模式 Builder Pattern | ★★★★☆ | ★★☆☆☆ |
| 結構型模式 Structural Pattern | 適配器模式 Adapter Pattern | ★★☆☆☆ | ★★★★☆ |
| 結構型模式 | 橋接模式 Bridge Pattern | ★★★☆☆ | ★★★☆☆ |
| 結構型模式 | 組合模式 Composite Pattern | ★★★☆☆ | ★★★★☆ |
| 結構型模式 | 裝飾模式 Decorator Pattern | ★★★☆☆ | ★★★☆☆ |
| 結構型模式 | 外觀模式 Façade Pattern | ★☆☆☆☆ | ★★★★★ |
| 結構型模式 | 享元模式 Flyweight Pattern | ★★★★☆ | ★☆☆☆☆ |
| 結構型模式 | 代理模式 Proxy Pattern | ★★★☆☆ | ★★★★☆ |
| 行爲型模式 Behavioral Pattern | 職責鏈模式 Chain of Responsibility Pattern | ★★★☆☆ | ★★☆☆☆ |
| 行爲型模式 | 命令模式 Command Pattern | ★★★☆☆ | ★★★★☆ |
| 行爲型模式 | 解釋器模式 Interpreter Pattern | ★★★★★ | ★☆☆☆☆ |
| 行爲型模式 | 迭代器模式 Iterator Pattern | ★★★☆☆ | ★★★★★ |
| 行爲型模式 | 中介者模式 Mediator Pattern | ★★★☆☆ | ★★☆☆☆ |
| 行爲型模式 | 備忘錄模式 Memento Pattern | ★★☆☆☆ | ★★☆☆☆ |
| 行爲型模式 | 觀察者模式 Observer Pattern | ★★★☆☆ | ★★★★★ |
| 行爲型模式 | 狀態模式 State Pattern | ★★★☆☆ | ★★★☆☆ |
| 行爲型模式 | 策略模式 Strategy Pattern | ★☆☆☆☆ | ★★★★☆ |
| 行爲型模式 | 模板方法模式 Template Method Pattern | ★★☆☆☆ | ★★★☆☆ |
| 行爲型模式 | 訪問者模式 Visitor Pattern | ★★★★☆ | ★☆☆☆☆ |
三、爲什麼用設計模式(why)
(1) 設計模式來源衆多專家的經驗和智慧，它們是從許多優秀的軟件系統中總結出的成功的、能夠實現可維護性複用的設計方案，使用這些方案將可以讓我們避免做一些重複性的工作，也許我們冥思苦想得到的一個“自以爲很了不起”的設計方案其實就是某一個設計模式。在時間就是金錢的今天，設計模式無疑會爲有助於我們提高開發和設計效率，但它不保證一定會提高，微笑。
(2) 設計模式提供了一套通用的設計詞彙和一種通用的形式來方便開發人員之間溝通和交流，使得設計方案更加通俗易懂。交流通常很耗時，任何有助於提高交流效率的東西都可以爲我們節省不少時間。無論你使用哪種編程語言，做什麼類型的項目，甚至你處於一個國際化的開發團隊，當面對同一個設計模式時，你和別人的理解並無二異，因爲設計模式是跨語言、跨平臺、跨應用、跨國界的。通俗，大家都懂！
(3) 大部分設計模式都兼顧了系統的可重用性和可擴展性，這使得我們可以更好地重用一些已有的設計方案、功能模塊甚至一個完整的軟件系統，避免我們經常做一些重複的設計、編寫一些重複的代碼。此外，隨着軟件規模的日益增大，軟件壽命的日益變長，系統的可維護性和可擴展性也越來越重要，許多設計模式將有助於提高系統的靈活性和可擴展性，讓我們在不修改或者少修改現有系統的基礎上增加、刪除或者替換功能模塊。如果一點設計模式都不懂，我想要做到這一點恐怕還是很困難的。
(4) 最後一點對初學者很重要，學習設計模式將有助於初學者更加深入地理解面向對象思想，讓你知道：如何將代碼分散在幾個不同的類中？爲什麼要有“接口”？何謂針對抽象編程？何時不應該使用繼承？如果不修改源代碼增加新功能？同時還讓你能夠更好地閱讀和理解現有類庫（如JDK）與其他系統中的源代碼，讓你早點脫離面向對象編程的“菜鳥期”。
(5)我覺得最重要的是，許多公司在面試的時候都會問，熟悉設計模式嗎，瞭解設計模式嗎，用過設計模式嗎，如果你會不一定加分，如果你不會但一定會被減分的。
四、怎樣學習設計模式(how)
1、看書，在互聯網不發達的時候，這是獲取知識最原始的途徑。市面上關於設計模式的書真的很多，估計很多人都會挑花眼。
《大話設計模式》還成，裏面的語言是C#，然而C#和Java很像
《設計模式之禪（第2版）》這本書我翻了一下，感覺還不錯，用Java寫的
《圖解設計模式》，圖解系列對新手是非常友好的，也是用Java寫的，推薦
2、看博客、這個對於許多人來說都特別方便，一個電腦，一臺手機知識隨時隨地學習，這個自己搜索吧。
3、看優秀開源軟件的源代碼，這個比較難，但對於對設計模式的理解是最快的，也是最深入的。Java的源碼、dubbo源碼、Spring 、SpringBoot等等
4、多寫、就是多多練習寫設計模式，當你能把一種設計模式寫到非常熟悉的時候，你就對設計模式非常瞭解了。