title: 設計模式筆記-大綱
date: 2019-04-25 09:49:37
tags: 設計模式
作者：muggle
設計模式的分類
創建型模式
共五種：
- 工廠方法模式
- 抽象工廠模式
- 單例模式
- 建造者模式
- 原型模式
結構型模式
共七種：
- 適配器模式
- 裝飾器模式
- 代理模式
- 外觀模式
- 橋接模式
- 組合模式
- 享元模式
行爲型模式
共十一種：
- 策略模式
- 模板方法模式
- 觀察者模式
- 迭代子模式
- 責任鏈模式
- 命令模式
- 備忘錄模式
- 狀態模式
- 訪問者模式
- 中介者模式
- 解釋器模式
設計原則
設計模式的最終目的是爲了實現代碼設計的六大基本原則的，我們在使用設計模式的時候千萬要記住這一點，不用爲了使用設計模式而去強行套設計模式
單一職責原則
不要存在多於一個導致類變更的原因，也就是說每個類應該實現單一的職責，如若不然，就應該把類拆分。
當需求變化時，將通過更改職責相關的類來體現。如果一個類擁有多於一個的職責，則多個職責耦合在一起，會有多於一個原因來導致這個類發生變化。一個職責的變化可能會影響到其他的職責，另外，把多個職責耦合在一起，影響複用性。
單一職責原則解決的問題：
- 降低類的複雜度；
- 提高類的可讀性，提高系統的可維護性；
- 降低變更引起的風險（降低對其他功能的影響）。
里氏替換原則
任何基類可以出現的地方，子類一定可以出現。
只有當子類可以替換掉父類， 代碼功能不受到影響時，父類才能真正被複用， 而子類也能夠在父類的基礎上增加新的行爲；從而達到代碼複用與擴展的目的；里氏替換原則中，子類對父類的方法儘量不要重寫和重載。因爲父類代表了定義好的結構，通過這個規範的接口與外界交互，子類不應該隨便破壞它。
里氏替換原則解決的問題：
- 增強程序的健壯性， 版本升級時也可以保持非常好的兼容性。
- 提高代碼複用率
依賴倒置原則
這個是開閉原則的基礎，具體內容：面向接口編程，依賴於抽象而不依賴於具體。寫代碼時用到具體類時，不與具體類交互，而與具體類的上層接口交互。
開閉原則
對於引用的模塊儘量去擴展，而不是去修改它，也就是所謂的對擴展開放對修改關閉。開閉原則是面向對象的可複用設計的第一塊基石，它是最重要的面向對象設計原則，抽象化是開閉原則的關鍵。
接口隔離原則
接口隔離原則(Interface Segregation Principle, ISP)：使用多個專門的接口，而不使用單一的總接口，即客戶端不應該依賴那些它不需要的接口。 根據接口隔離原則，當一個接口太大時，我們需要將它分割成一些更細小的接口，使用該接口的客戶端僅需知道與之相關的方法即可
迪米特原則
一個類應該對自己需要耦合或調用的類知道得最少，類的內部如何實現、如何複雜都與調用者或者依賴者沒關係，調用者或者依賴者只需要知道他需要的方法即可，其他的我一概不關心。類與類之間的關係越密切，耦合度越大，當一個類發生改變時，對另一個類的影響也越大。
設計模式解析
首先允許我提一點建議，有不少設計模式的教程喜歡拿生活中一些事物舉例子，比如什麼什麼奧迪汽車，寶馬，汽車工廠這種。這種方式確實能讓人更加直觀的的體會到一個設計模式的用法和作用，但是我以前這樣學的後果就是——看啥都像設計模式，想往設計模式裏面套又套不出個所以然來。實際上有的設計模式結構是由好幾個角色組成，該如何去寫怎麼命名都是確定的有理有據的，你光記住生活中的一個例子然後平時寫代碼去套這個例子，你會有種無從下手的感覺。我們應該把每個設計模式的使用場景結構都記住，但是這樣死記難記不說，還很難做到活學活用。我的的建議是結合源碼去記，這樣你能根據源碼中的例子依瓢畫葫蘆寫出自己想要的設計模式出來，我接下來對設計模式的講解也是結合源碼進行講解的。
然後，我個人建議是能不用設計模式的地方就不用設計模式。並不是因爲設計模式不好，一個設計得好的設計模式確實可以減少我們工作量和代碼維護成本，但是一個設計不好的設計模式使用起來代價巨大。要知道設計模式的最終目的是減少我們的工作量，不要爲了設計模式而設計模式。一個垃圾的設計模式的缺點：代碼維護成本翻倍，因爲會憑空多了好多莫名其妙的類；代碼讀不懂，你設計模式用的亂七八糟，別人只會感覺你的代碼毫無邏輯，繞來繞去。
一個好的設計模式，首先要用對場景，然後命名要規範，要讓別人一看命名就知道你用的什麼設計模式，然後根據設計模式去找相關聯的類，這樣別人腦海裏才能形成一個脈絡，有點沒法按設計模式規範命名的地方也請加上註釋，不然讓別人猜你的代碼寫了些啥，用的啥設計模式嗎？
個人公衆號：