23種設計模式（GOF）
背景–出來混總是要還的
說起設計模式，我是不願意提起的，原因無外乎設計模式理論性太強，沒有豐富的項目實踐經驗，跟本無法體會設計模式對於開發的指導的重要性。換句話說就是，理論及其反人類，說明又臭又長，反正就是看不進去。
寫了2+年的項目代碼，其中見識過一個方下單的法都寫了幾百行；碼代碼明確對自己缺乏設計的代碼困惑時；各種重複到噁心的代碼，確無從下手整合。
好像設計模式是講軟件設計的，翻翻去，，，，看了幾遍，還是TM難以理解。
最近又找上工作，感覺自己這一塊實在是薄弱得不行不行地，趕緊惡補一波。
說巧不巧，不小心看到了C語言中文網，資料完整，綜合完整理論、uml圖、代碼講解透徹，反正理論和實例都非常貼合，看完都不帶有啥疑惑的
（要是當年學設計模式的時候，老師能夠用這份資料來講課，嗯嗯嗯，我一樣不會聽的，只是找起資料來就應該不會有被網上各種設計模式給折騰半死。本帥的搜索、歸納整理的能力還有很大的進步空間嘛！！）
再次開始設計模式之旅，順便做一次備忘錄。。。。
軟件設計模式
爲什麼要學軟件設計模式
正如上面所說，bs是真的遇到自己的困惑了，而軟件設計模式恰好可以解除我的迷惑，設計經驗總結來的
軟件設計模式：是一套被反覆使用、多數人知曉、經過分類編目的、代碼設計經驗的總結。 它描述了在軟件設計過程中一些不斷重複發生的問題，以及該問題的解決方案。
目的：爲了提高代碼的可重用性、代碼的可讀性和代碼的可靠性。
本質：面向對象設計原則的充分應用，對類的封裝性，繼承性、多態性以及類的關聯關係、組合關係的充分理解
而正確使用設計模式又有如下好處：
- 提高bs的編程能力、思維能力，設計能力；
- 程序設計設計標準化，代碼編制工程化，軟件開發效率大大提高
- 代碼可重用性高，可讀性強、可靠性高、靈活性好、可維護性強
講道理這就是bs需要的麼！！(^_^)
7條原則
| 原則 | 說明 | 個人想法 |
|---|---|---|
| 開閉原則（Open Closed Principle，OCP） | 對修改關閉，對拓展開放 | 總原則，一切基礎 |
| 里氏替換原則（Liskov Substitution Principle，LSP） | 繼承必須確保超類所擁有的性質在子類中仍然成立 | 類關係-繼承 子類可以擴展父類的功能，但不能改變父類原有的功能 |
| 依賴倒置原則（Dependence Inversion Principle，DIP） | 高層模塊不應該依賴低層模塊，兩者都應該依賴其抽象；抽象不應該依賴細節，細節應該依賴抽象 | 類關係-調用 要面向接口編程，不面向實現編程。 |
| 單一職責原則（Single Responsibility Principle，SRP） | 一個類應該有且僅有一個引起它變化的原因，否則類應該被拆分 | 類產生 簡單化一個類的職責 |
| 接口隔離原則（Interface Segregation Principle，ISP） | 要爲各個類建立它們需要的專用接口，而不要試圖去建立一個很龐大的接口供所有依賴它的類去調用 | 接口拆分原則 |
| 迪米特法則（Law of Demeter，LoD） | 最少知道原則最少知識原則（Least Knowledge Principle，LKP)，如果兩個軟件實體無須直接通信，那麼就不應當發生直接的相互調用，可以通過第三方轉發該調用 | 降低類之間的耦合度，提高模塊的相對獨立性 隱藏細節，減少沒必要的調用 |
| 合成複用原則（Composite Reuse Principle，CRP） | 組合/聚合複用原則（Composition/Aggregate Reuse Principle，CARP）在軟件複用時，要儘量先使用組合或者聚合等關聯關係來實現，其次才考慮使用繼承關係來實現。 | 基於開閉原則推薦 |
軟件設計模式的分類：
- 根據目的來分
根據模式是用來完成什麼工作來劃分，這種方式可分爲創建型模式、結構型模式和行爲型模式 3 種。- 創建型模式：用於描述“怎樣創建對象”，它的主要特點是“將對象的創建與使用分離”。GoF 中提供了單例、原型、工廠方法、抽象工廠、建造者等 5 種創建型模式。
- 結構型模式：用於描述如何將類或對象按某種佈局組成更大的結構，GoF 中提供了代理、適配器、橋接、裝飾、外觀、享元、組合等 7 種結構型模式。
- 行爲型模式：用於描述類或對象之間怎樣相互協作共同完成單個對象都無法單獨完成的任務，以及怎樣分配職責。GoF 中提供了模板方法、策略、命令、職責鏈、狀態、觀察者、中介者、迭代器、訪問者、備忘錄、解釋器等 11 種行爲型模式。
- 根據作用範圍來分
根據模式是主要用於類上還是主要用於對象上來分，這種方式可分爲類模式和對象模式兩種。- 類模式：用於處理類與子類之間的關係，這些關係通過繼承來建立，是靜態的，在編譯時刻便確定下來了。GoF中的工廠方法、（類）適配器、模板方法、解釋器屬於該模式。
- 對象模式：用於處理對象之間的關係，這些關係可以通過組合或聚合來實現，在運行時刻是可以變化的，更具動態性。GoF 中除了以上 4 種，其他的都是對象模式。
- GoF的23種設計模式的功能
前面說明了 GoF 的 23 種設計模式的分類，現在對各個模式的功能進行介紹。- 單例（Singleton）模式：某個類只能生成一個實例，該類提供了一個全局訪問點供外部獲取該實例，其拓展是有限多例模式。
- 原型（Prototype）模式：將一個對象作爲原型，通過對其進行復制而克隆出多個和原型類似的新實例。
- 工廠方法（Factory Method）模式：定義一個用於創建產品的接口，由子類決定生產什麼產品。
- 抽象工廠（AbstractFactory）模式：提供一個創建產品族的接口，其每個子類可以生產一系列相關的產品。
- 建造者（Builder）模式：將一個複雜對象分解成多個相對簡單的部分，然後根據不同需要分別創建它們，最後構建成該複雜對象。
- 代理（Proxy）模式：爲某對象提供一種代理以控制對該對象的訪問。即客戶端通過代理間接地訪問該對象，從而限制、增強或修改該對象的一些特性。
- 適配器（Adapter）模式：將一個類的接口轉換成客戶希望的另外一個接口，使得原本由於接口不兼容而不能一起工作的那些類能一起工作。
- 橋接（Bridge）模式：將抽象與實現分離，使它們可以獨立變化。它是用組合關係代替繼承關係來實現，從而降低了抽象和實現這兩個可變維度的耦合度。
- 裝飾（Decorator）模式：動態的給對象增加一些職責，即增加其額外的功能。
- 外觀（Facade）模式：爲多個複雜的子系統提供一個一致的接口，使這些子系統更加容易被訪問。
- 享元（Flyweight）模式：運用共享技術來有效地支持大量細粒度對象的複用。
- 組合（Composite）模式：將對象組合成樹狀層次結構，使用戶對單個對象和組合對象具有一致的訪問性。
- 模板方法（TemplateMethod）模式：定義一個操作中的算法骨架，而將算法的一些步驟延遲到子類中，使得子類可以不改變該算法結構的情況下重定義該算法的某些特定步驟。
- 策略（Strategy）模式：定義了一系列算法，並將每個算法封裝起來，使它們可以相互替換，且算法的改變不會影響使用算法的客戶。
- 命令（Command）模式：將一個請求封裝爲一個對象，使發出請求的責任和執行請求的責任分割開。
- 職責鏈（Chain of Responsibility）模式：把請求從鏈中的一個對象傳到下一個對象，直到請求被響應爲止。通過這種方式去除對象之間的耦合。
- 狀態（State）模式：允許一個對象在其內部狀態發生改變時改變其行爲能力。
- 觀察者（Observer）模式：多個對象間存在一對多關係，當一個對象發生改變時，把這種改變通知給其他多個對象，從而影響其他對象的行爲。
- 中介者（Mediator）模式：定義一箇中介對象來簡化原有對象之間的交互關係，降低系統中對象間的耦合度，使原有對象之間不必相互瞭解。
- 迭代器（Iterator）模式：提供一種方法來順序訪問聚合對象中的一系列數據，而不暴露聚合對象的內部表示。
- 訪問者（Visitor）模式：在不改變集合元素的前提下，爲一個集合中的每個元素提供多種訪問方式，即每個元素有多個訪問者對象訪問。
- 備忘錄（Memento）模式：在不破壞封裝性的前提下，獲取並保存一個對象的內部狀態，以便以後恢復它。
- 解釋器（Interpreter）模式：提供如何定義語言的文法，以及對語言句子的解釋方法，即解釋器。
總結
這些都是基礎以後是需要好好補充，完善
任重而道遠，說得任務不重道路就不遠一樣@_@