設計模式相信很多人都應該聽過，但是具體是什麼可能就有點說不出個所以然，因爲你只是聽過，但是沒有經過系統性的學習，所以很難說出設計模式到底是什麼，在接下來的一段時間我將帶領大家一起進入手撕設計模式階段的學習。
GOF（四人幫，全拼 Gang of Four）
在 1994 年，由 Erich Gamma、Richard Helm、Ralph Johnson 和 John Vlissides 四人合著出版了一本名爲 Design Patterns - Elements of Reusable Object-Oriented Software（中文譯名：設計模式 - 可複用的面向對象軟件元素） 的書，該書首次提到了軟件開發中設計模式的概念。
他們所提出的設計模式主要是基於以下的面向對象設計原則。
- 對接口編程而不是對實現編程。
- 優先使用對象組合而不是繼承。
設計模式概念：
軟件設計模式（Software Design Pattern），又稱設計模式，是一套被反覆使用、多數人知曉的、經過分類編目的、代碼設計經驗的總結。它描述了在軟件設計過程中的一些不斷重複發生的問題，以及該問題的解決方案。也就是說，它是解決特定問題的一系列套路，是前輩們的代碼設計經驗的總結，具有一定的普遍性，可以反覆使用。其目的是爲了提高代碼的可重用性、代碼的可讀性和代碼的可靠性。 設計模式的本質是面向對象設計原則的實際運用，是對類的封裝性、繼承性和多態性以及類的關聯關係和組合關係的充分理解。
學習設計模式的意義：
- 可以提高程序員的思維能力、編程能力和設計能力。
- 使程序設計更加標準化、代碼編制更加工程化，使軟件開發效率大大提高，從而縮短軟件的開發週期。
- 使設計的代碼可重用性高、可讀性強、可靠性高、靈活性好、可維護性強。
- 使程序呈現高內聚，低耦合的特性
設計模式的七大原則：
-
單一職責原則：單一職責原則（Single Responsibility Principle，SRP）又稱單一功能原則，由羅伯特·C.馬丁（Robert C. Martin）於《敏捷軟件開發：原則、模式和實踐》一書中提出的。這裏的職責是指類變化的原因，單一職責原則規定一個類應該有且僅有一個引起它變化的原因，否則類應該被拆分（There should never be more than one reason for a class to change）。 -
接口隔離原則：接口隔離原則（Interface Segregation Principle，ISP）要求程序員儘量將臃腫龐大的接口拆分成更小的和更具體的接口，讓接口中只包含客戶感興趣的方法,它強調降低依賴，降低耦合。 -
依賴倒轉原則：依賴倒轉原則（Dependence Inversion Principle，DIP）這個原則是開閉原則的基礎。其核心思想是：要面向接口編程，不要面向實現編程。 -
里氏替換原則：里氏替換原則（Liskov Substitution Principle，LSP）是面向對象設計的基本原則之一。 里氏替換原則中說，任何基類可以出現的地方，子類一定可以出現。里氏替換原則是繼承複用的基石，只有當派生類可以替換掉基類，且軟件單位的功能不受到影響時，基類才能真正被複用，而派生類也能夠在基類的基礎上增加新的行爲。里氏代換原則是對開閉原則的補充。實現開閉原則的關鍵步驟就是抽象化，而基類與子類的繼承關係就是抽象化的具體實現，所以里氏替換原則是對實現抽象化的具體步驟的規範。 -
開閉原則：開閉原則（Open Close Principle，OCP）指的是軟件實體應當對擴展開放，對修改關閉。在程序需要進行拓展的時候，不能去修改原有的代碼，實現一個熱插拔的效果。簡言之，是爲了使程序的擴展性好，易於維護和升級。 -
迪米特法則：迪米特法則（Law of Demeter，LoD）又叫最少知道原則。它指的是一個實體應當儘量少地與其他實體之間發生相互作用，使得系統功能模塊相對獨立。 -
合成複用原則：合成複用原則（Composite Reuse Principle，CRP）又叫組合/聚合複用原則。它要求在軟件複用時，要儘量先使用組合或者聚合等關聯關係來實現，其次才考慮使用繼承關係來實現。如果真的要使用繼承關係，則必須嚴格遵循里氏替換原則。合成複用原則同里氏替換原則相輔相成的，兩者都是開閉原則的具體實現規範。
設計模式的分類：
-
創建型：對象實例化的模式，創建型模式用於解耦對象的實例化過程。
-
結構型：把類或對象結合在一起形成一個更大的結構。
-
行爲型：類和對象如何交互，及劃分責任和算法。
如下圖所示：
23種設計模式的特點：
- 單例模式：某個類只能有一個實例，提供一個全局的訪問點。
- 工廠方法模式：定義一個創建對象的接口，讓子類決定去實例化哪個類。
- 抽象工廠模式：創建相關或依賴對象的家族，而無需明確指定具體類。
- 建造者模式：封裝一個複雜對象的構建過程，並可以按步驟構造。
- 原型模式：通過複製現有的實例來創建新的實例。
- 適配器模式：將一個類的方法接口轉換成客戶端希望的另外一個接口。
- 橋接模式：將抽象部分和它的實現部分分離，使它們都可以獨立的變化。
- 組合模式：將對象組合成樹形結構以表示 “ 部分-整體 “ 的層次結構。
- 裝飾模式：動態的給對象添加新的功能。
- 外觀模式：對外提供一個統一的方法，來訪問子系統中的一組接口。
- 享元模式：通過共享技術來有效的支持大量細粒度的對象。
- 代理模式：爲其他對象提供一個代理，以便控制這個對象的訪問。
- 訪問者模式：在不改變數據結構的前提下，增加一組作用於對象元素的新功能。
- 模板模式：定義一個算法結構，而將一些步驟延遲到子類實現。
- 策略模式：定義一系列算法，把它們封裝起來，並且使它們可以相互替換。
- 狀態模式：允許一個對象在其對象內部狀態改變時改變它的行爲。
- 觀察者模式：對象間的一對多的依賴關係。
- 備忘錄模式：在不破壞封裝的前提下，保持對象的內部狀態。
- 中介者模式：用一箇中介對象來封裝一系列的對象交互。
- 迭代器模式：一種遍歷訪問聚合對象中各個元素的方法，且不暴露該對象的內部結構。
- 解釋器模式：給定一個語言，定義它的文法的一種表示，並定義一個解釋器。
- 命令模式：將命令請求封裝爲一個對象，使得可以用不同的請求來進行參數化。
- 責任鏈模式：將請求的發送者和接收者解耦，使得多個對象都有處理這個請求的機會。
至此，軟件設計模式的介紹就基本上講解完畢了，後續我會對這23種不同的設計模式進行一一講解，敬請期待。