設計模式筆記-大綱

---

title: 設計模式筆記-大綱
date: 2019-04-25 09:49:37
tags: 設計模式

---

做者：muggle

設計模式的分類

建立型模式

共五種：

• 工廠方法模式
• 抽象工廠模式
• 單例模式
• 建造者模式
• 原型模式

結構型模式

共七種：

• 適配器模式
• 裝飾器模式
• 代理模式
• 外觀模式
• 橋接模式
• 組合模式
• 享元模式

行爲型模式

共十一種：

• 策略模式
• 模板方法模式
• 觀察者模式
• 迭代子模式
• 責任鏈模式
• 命令模式
• 備忘錄模式
• 狀態模式
• 訪問者模式
• 中介者模式
• 解釋器模式

設計原則

設計模式的最終目的是爲了實現代碼設計的六大基本原則的，咱們在使用設計模式的時候千萬要記住這一點，不用爲了使用設計模式而去強行套設計模式

單一職責原則

不要存在多於一個致使類變動的緣由，也就是說每一個類應該實現單一的職責，如若否則，就應該把類拆分。

當需求變化時，將經過更改職責相關的類來體現。若是一個類擁有多於一個的職責，則多個職責耦合在一塊兒，會有多於一個緣由來致使這個類發生變化。一個職責的變化可能會影響到其餘的職責，另外，把多個職責耦合在一塊兒，影響複用性。

單一職責原則解決的問題：

• 下降類的複雜度；
• 提升類的可讀性，提升系統的可維護性；
• 下降變動引發的風險（下降對其餘功能的影響）。

里氏替換原則

任何基類能夠出現的地方，子類必定能夠出現。

只有當子類能夠替換掉父類， 代碼功能不受到影響時，父類才能真正被複用， 而子類也可以在父類的基礎上增長新的行爲；從而達到代碼複用與擴展的目的；里氏替換原則中，子類對父類的方法儘可能不要重寫和重載。由於父類表明了定義好的結構，經過這個規範的接口與外界交互，子類不該該隨便破壞它。

里氏替換原則解決的問題：

• 加強程序的健壯性， 版本升級時也能夠保持很是好的兼容性。
• 提升代碼複用率

依賴倒置原則

這個是開閉原則的基礎，具體內容：面向接口編程，依賴於抽象而不依賴於具體。寫代碼時用到具體類時，不與具體類交互，而與具體類的上層接口交互。

開閉原則

對於引用的模塊儘可能去擴展，而不是去修改它，也就是所謂的對擴展開放對修改關閉。開閉原則是面向對象的可複用設計的第一塊基石，它是最重要的面向對象設計原則，抽象化是開閉原則的關鍵。

接口隔離原則

接口隔離原則(Interface Segregation Principle, ISP)：使用多個專門的接口，而不使用單一的總接口，即客戶端不該該依賴那些它不須要的接口。 根據接口隔離原則，當一個接口太大時，咱們須要將它分割成一些更細小的接口，使用該接口的客戶端僅需知道與之相關的方法便可

迪米特原則

一個類應該對本身須要耦合或調用的類知道得最少，類的內部如何實現、如何複雜都與調用者或者依賴者不要緊，調用者或者依賴者只須要知道他須要的方法便可，其餘的我一律不關心。類與類之間的關係越密切，耦合度越大，當一個類發生改變時，對另外一個類的影響也越大。

設計模式解析

首先容許我提一點建議，有很多設計模式的教程喜歡拿生活中一些事物舉例子，好比什麼什麼奧迪汽車，寶馬，汽車工廠這種。這種方式確實能讓人更加直觀的的體會到一個設計模式的用法和做用，可是我之前這樣學的後果就是——看啥都像設計模式，想往設計模式裏面套又套不出個因此然來。實際上有的設計模式結構是由好幾個角色組成，該如何去寫怎麼命名都是肯定的有理有據的，你光記住生活中的一個例子而後平時寫代碼去套這個例子，你會有種無從下手的感受。咱們應該把每一個設計模式的使用場景結構都記住，可是這樣死記難記不說，還很難作到活學活用。個人的建議是結合源碼去記，這樣你能根據源碼中的例子依瓢畫葫蘆寫出本身想要的設計模式出來，我接下來對設計模式的講解也是結合源碼進行講解的。

而後，我我的建議是能不用設計模式的地方就不用設計模式。並非由於設計模式很差，一個設計得好的設計模式確實能夠減小咱們工做量和代碼維護成本，可是一個設計很差的設計模式使用起來代價巨大。要知道設計模式的最終目的是減小咱們的工做量，不要爲了設計模式而設計模式。一個垃圾的設計模式的缺點：代碼維護成本翻倍，由於會憑空多了好多莫名其妙的類；代碼讀不懂，你設計模式用的亂七八糟，別人只會感受你的代碼毫無邏輯，繞來繞去。

一個好的設計模式，首先要用對場景，而後命名要規範，要讓別人一看命名就知道你用的什麼設計模式，而後根據設計模式去找相關聯的類，這樣別人腦海裏才能造成一個脈絡，有點無法按設計模式規範命名的地方也請加上註釋，否則讓別人猜你的代碼寫了些啥，用的啥設計模式嗎？