設計模式 - 設計原則

目錄

• 設計模式
  • 設計原則
    • 單一職責原則 SRP(Single Responsibilities Principle)
    • 接口隔離原則 ISP(Interface Segregation Principle)
    • 依賴倒置原則 DIP(Dependence Inversion Principle)
    • 裏式替換原則 LSK(Liskov Substitution Principle)
    • 開閉原則 OCP(Open Close Principle)
    • 迪米特法則 DP (Demeter Principle)
  • UML
  • 設計模式類型
    • 建立型模式
    • 結構型模式
    • 行爲型模式
    • JavaEE模式

---

設計模式

設計原則

在面向對象設計模式中存在的是五大原則和一個法則。

• 單一職責原則 SRP(Single Responsibilities Principle)
• 接口隔離原則 ISP(Interface Segregation Principle)
• 依賴倒置原則 DIP(Dependence Inversion Principle)
• 里氏替換原則 LSK(Liskov Substitution Principle)
• 開閉原則 OCP(Open Close Principle)
• 迪米特法則 DP (Demeter Principle)

單一職責原則 SRP(Single Responsibilities Principle)

# 1.單一職責原則
- 參考文檔:https://baike.baidu.com/item/%E5%8D%95%E4%B8%80%E8%81%8C%E8%B4%A3%E5%8E%9F%E5%88%99/9456515?fr=aladdin

- 一個類只負責一項職責。

# 2.單一職責優勢
- 下降類的複雜度，一個類只負責一個職責。這樣寫出來的代碼邏輯確定要比負責多項職責簡單得多。

- 提升類的可讀性，提升系統的可維護性。

- 下降變動引發的風險。變動是必然的，若是單一職責原則遵照得好，當修改一個功能的時候能夠顯著下降對其餘功能的影響。

須要說明的一點是，單一職責原則不僅是面向對象編程思想所特有的，只要是模塊化的程序設計，都適用單一職責原則。好比說單一職責原則不只僅適用於類，還適用於方法。

# 3.單一職責注意事項
一般狀況下，咱們應當遵照單一職責原則，只有邏輯足夠簡單，才能夠在代碼級違反單一職責原則；只有類中方法數量足夠少，能夠在方法級別保持單一職責原則。

接口隔離原則 ISP(Interface Segregation Principle)

# 1.接口隔離原則
- 參考文檔:https://baike.baidu.com/item/%E6%8E%A5%E5%8F%A3%E9%9A%94%E7%A6%BB%E5%8E%9F%E5%88%99/3104602?fr=aladdin

- 一個類對另外一個類的依賴應該創建在最小的接口上。

- 一個接口表明一個角色，不該當將不一樣的角色都交給一個接口。沒有關係的接口合併在一塊兒，造成一個臃腫的大接口，這是對角色和接口的污染。

- 「不該該強迫客戶依賴於它們不用的方法。接口屬於客戶，不屬於它所在的類層次結構。」這個說得很明白了，再通俗點說，不要強迫客戶使用它們不用的方法，若是強迫用戶使用它們不使用的方法，那麼這些客戶就會面臨因爲這些不使用的方法的改變所帶來的改變。

依賴倒置原則 DIP(Dependence Inversion Principle)

# 1.倒轉依賴原則
- 參考文檔:https://baike.baidu.com/item/%E4%BE%9D%E8%B5%96%E5%80%92%E7%BD%AE%E5%8E%9F%E5%88%99/6189149?fr=aladdin

- 程序要依賴於抽象接口，不要依賴於具體實現。簡單的說就是要求對抽象進行編程，不要對實現進行編程，這樣就下降了客戶與實現模塊間的耦合。

- 高層模塊不該該依賴低層模塊，兩者都應該依賴其抽象。

- 抽象不該該依賴細節，細節應該依賴抽象。

- 依賴倒轉(倒置)的中心思想是面向接口編程。

- 依賴倒轉原則是基於這樣的設計理念：相對於細節的多變性，抽象的東西要穩定的多。以抽象爲基礎搭建的架構比以細節爲基礎的架構要穩定的多。在java中，抽象指的是接口或抽象類，細節就是具體的實現類。

- 使用接口或抽象類的目的是制定好規範，而不涉及任何具體的操做，把展示細節的任務交給他們的實現類去完成。

# 2.倒轉依賴方式
- 接口傳遞

- 構造方法傳遞

- setter方式傳遞

# 3.倒轉依賴注意事項
- 低層模塊儘可能都要有抽象類或接口，或者二者都有，程序穩定性更好。

- 變量的聲明類型儘可能是抽象類或接口, 這樣咱們的變量引用和實際對象間，就存在一個緩衝層，利於程序擴展和優化。

- 繼承時遵循里氏替換原則。

裏式替換原則 LSK(Liskov Substitution Principle)

# 1.裏式替換原則
- 參考文檔:https://baike.baidu.com/item/%E9%87%8C%E6%B0%8F%E6%9B%BF%E6%8D%A2%E5%8E%9F%E5%88%99/3744239?fr=aladdin

- 繼承在給程序設計帶來便利的同時,也帶來了弊端。好比使用繼承會給程序帶來侵入性,程序的可移植性下降,增長對象間的耦合性,若是一個類被其餘的類所繼承,則當這個類須要修改時,必須考慮到全部的子類,而且父類修改後,全部涉及到子類的功能都有可能產生故障。

- 在使用繼承時,遵循里氏替換原則,在子類中儘可能不要重寫父類的方法。

- 里氏替換原則代表繼承實際上讓兩個類耦合性加強了,在適當的狀況下,能夠經過聚合、組合、依賴 來解決問題。

- 重寫父類的方法,可能會形成原有功能出現錯誤。因此父類和子類都繼承一個更通俗的基類,原有的繼承關係去掉,採用依賴、聚合、組合等關係代替。

開閉原則 OCP(Open Close Principle)

# 1.開閉原則
- 參考文檔:https://baike.baidu.com/item/%E5%BC%80%E9%97%AD%E5%8E%9F%E5%88%99/2828775?fr=aladdin

-開閉原則規定「軟件中的對象（類，模塊，函數等等）應該對於擴展是開放的，可是對於修改是封閉的」。

- 當軟件須要變化時,儘可能經過擴展軟件實體的行爲來實現變化,而不是經過修改已有的代碼來實現變化。

- 編程中遵循其它原則,以及使用設計模式的目的就是遵循開閉原則。

迪米特法則 DP (Demeter Principle)

# 1.迪米特法則
- 參考文檔:https://baike.baidu.com/item/%E8%BF%AA%E7%B1%B3%E7%89%B9%E6%B3%95%E5%88%99/2107000?fr=aladdin

- 迪米特法則(Law of Demeter)又叫做最少知識原則(The Least Knowledge Principle)，一個類對於其餘類知道的越少越好，就是說一個對象應當對其餘對象有儘量少的瞭解,只和朋友通訊，不和陌生人說話。英文簡寫爲: LOD。

- 迪米特法則的核心是下降類之間的耦合。

- 因爲每一個類都減小了沒必要要的依賴，所以迪米特法則只是要求下降類間(對象間)耦合關係， 並非要求徹底沒有依賴關係。

UML

# 1.UML
- 參考文檔:https://baike.baidu.com/item/%E7%BB%9F%E4%B8%80%E5%BB%BA%E6%A8%A1%E8%AF%AD%E8%A8%80/3160571?fromtitle=UML&fromid=446747&fr=aladdin

- UML採用一組圖形符號來描述軟件模型，這些圖形符號具備簡單、直觀和規範的特色，開發人員學習和掌握起來比較簡單。

# 2.類圖相關概念
- 依賴關係(Dependence)

- 泛化關係(generalization)

- 實現關係(Implementation)

- 關聯關係(Association)

- 聚合關係(Aggregation)

- 組合關係(Composition)

設計模式類型

建立型模式

這些設計模式提供了一種在建立對象的同時隱藏建立邏輯的方式，而不是使用 new 運算符直接實例化對象。這使得程序在判斷針對某個給定實例須要建立哪些對象時更加靈活。

建立型模式提供建立對象的機制， 可以提高已有代碼的靈活性和可復⽤性。

- 工廠模式(Factory Pattern)
- 抽象工廠模式(Abstract Factory Pattern)
- 單例模式(Singleton Pattern)
- 建造者模式(Builder Pattern)
- 原型模式(Prototype Pattern)

結構型模式

這些設計模式關注類和對象的組合。繼承的概念被用來組合接口和定義組合對象得到新功能的方式。

結構型模式介紹如何將對象和類組裝成較⼤的結構， 並同時保持結構的靈活和⾼效。

- 適配器模式(Adapter Pattern)
- 橋接模式(Bridge Pattern)
- 過濾器模式(Filter、Criteria Pattern)
- 組合模式(Composite Pattern)
- 裝飾器模式(Decorator Pattern)
- 外觀模式(Facade Pattern)
- 享元模式(Flyweight Pattern)
- 代理模式(Proxy Pattern)

行爲型模式

這些設計模式特別關注對象之間的通訊。

行爲型模式負責對象間的⾼效溝通和職責委派。

- 責任鏈模式(Chain of Responsibility Pattern)
- 命令模式(Command Pattern)
- 解釋器模式(Interpreter Pattern)
- 迭代器模式(Iterator Pattern)
- 中介者模式(Mediator Pattern)
- 備忘錄模式(Memento Pattern)
- 觀察者模式(Observer Pattern)
- 狀態模式(State Pattern)
- 空對象模式(Null Object Pattern)
- 策略模式(Strategy Pattern)
- 模板模式(Template Pattern)
- 訪問者模式(Visitor Pattern)

JavaEE模式

這些設計模式特別關注表示層。這些模式是由 Sun Java Center 鑑定的。

- MVC 模式(MVC Pattern)
- 業務表明模式(Business Delegate Pattern)
- 組合實體模式(Composite Entity Pattern)
- 數據訪問對象模式(Data Access Object Pattern)
- 前端控制器模式(Front Controller Pattern)
- 攔截過濾器模式(Intercepting Filter Pattern)
- 服務定位器模式(Service Locator Pattern)
- 傳輸對象模式(Transfer Object Pattern)