java設計模式的基本原則有哪些

本篇內容介紹了“java設計模式的基本原則有哪些”的有關知識，在實際案例的操作過程中，不少人都會遇到這樣的困境，接下來就讓小編帶領大家學習一下如何處理這些情況吧！希望大家仔細閱讀，能夠學有所成！

設計模式（Design pattern）代表了程序開發的最佳實踐，通常被有經驗的面向對象的軟件開發人員所采用。設計模式是軟件開發人員在軟件開發過程中面臨的一般問題的解決方案。這些解決方案是眾多軟件開發人員經過相當長的一段時間的試驗和錯誤總結出來的，那設計模式有那些基本設計原則的呢？

通常來說，設計模式的基本原則包含以下 7 個內容：

1. 單一職責原則(Single Responsibility Principle)

   單一職責原則表示一個模塊的組成元素之間的功能相關性。從軟件變化的角度來看，就一個類而言，應該僅有一個讓它變化的原因；通俗地說，即一個類只負責一項職責。

• SRP 是一個簡單又直觀的原則，但是在實際編碼的過程中很難將它恰當地運用，需要結合實際情況進行運用。

• 單一職責原則可以降低類的復雜度，一個類僅負責一項職責，其邏輯肯定要比負責多項職責簡單。

• 提高了代碼的可讀性，提高系統的可維護性。

2. 開放-關閉原則(Open-Closed Principle)

   開放-關閉原則表示軟件實體 (類、模塊、函數等等) 應該是可以被擴展的，但是不可被修改。

   如果一個軟件能夠滿足 OCP 原則，那么它將有兩項優點：

• 能夠擴展已存在的系統，能夠提供新的功能滿足新的需求，因此該軟件有著很強的適應性和靈活性。

• 已存在的模塊，特別是那些重要的抽象模塊，不需要被修改，那么該軟件就有很強的穩定性和持久性。

3. 里氏替換原則(Liskov Substitution Principle)

   將一個基類對象替換成它的子類對象，程序將不會產生任何錯誤和異常，反過來則不成立，如果一個軟件實體使用的是一個子類對象的話，那么它不一定能夠使用基類對象。即子類可以擴展父類的功能，但不能改變父類原有的功能

4. 依賴倒轉原則(Dependence Inversion Principle)

   高層模塊不應該依賴低層模塊，二者都應該于抽象。進一步說，抽象不應該依賴于細節，細節應該依賴于抽象。遵循依賴倒轉原則可以降低類之間的耦合性，提高系統的穩定性，降低修改程序造成的風險。依賴倒轉原則的核心就是要我們面向接口編程

5. 接口隔離原則(Interface Segregation Principle)

   客戶端不應該依賴它不需要的接口；一個類對另一個類的依賴應該建立在最小的接口上

• 接口隔離原則的思想在于建立單一接口，盡可能地去細化接口，接口中的方法盡可能少

• 但是凡事都要有個度，如果接口設計過小，則會造成接口數量過多，使設計復雜化。所以一定要適度

6. 迪米特法則(Law Of Demeter)

   迪米特法則又稱為 最少知道原則，它表示一個對象應該對其它對象保持最少的了解。通俗來說就是，只與直接的朋友通信。

   直接的朋友：每個對象都會與其他對象有耦合關系，只要兩個對象之間有耦合關系，我們就說這兩個對象之間是朋友關系。耦合的方式很多，依賴、關聯、組合、聚合等。其中，我們稱出現成員變量、方法參數、方法返回值中的類為直接的朋友，而出現在局部變量中的類則不是直接的朋友。也就是說，陌生的類最好不要作為局部變量的形式出現在類的內部。

   對于被依賴的類來說，無論邏輯多么復雜，都盡量的將邏輯封裝在類的內部，對外提供 public 方法，不對泄漏任何信息。

7. 組合/聚合復用原則(Composite/Aggregate Reuse Principle)

   組合/聚合復用原則就是在一個新的對象里面使用一些已有的對象，使之成為新對象的一部分; 新的對象通過向這些對象的委派達到復用已有功能的目的。

   在面向對象的設計中，如果直接繼承基類，會破壞封裝，因為繼承將基類的實現細節暴露給子類；如果基類的實現發生了改變，則子類的實現也不得不改變；從基類繼承而來的實現是靜態的，不可能在運行時發生改變，沒有足夠的靈活性。于是就提出了組合/聚合復用原則，也就是在實際開發設計中，盡量使用組合/聚合，不要使用類繼承。

• 總體說來，組合/聚合復用原則告訴我們：組合或者聚合好過于繼承

• 聚合組合是一種 “黑箱” 復用，因為細節對象的內容對客戶端來說是不可見的

“java設計模式的基本原則有哪些”的內容就介紹到這里了，感謝大家的閱讀。如果想了解更多行業相關的知識可以關注億速云網站，小編將為大家輸出更多高質量的實用文章！