單一職責原則

? ? ?對類來說,即一個類應該只負責一項職責。如A類負責兩個不同的職責:職責1，職責2。當職責1需求變更而改變A時,可能造成職責2執行錯誤。所以需要將類A的粒度分解為A1,A2。

? ?①降低類的復雜度,一個類只負責一項職責。

? ?②提高類的可讀性，可維護性。

? ?③降低變更引起的風險。

? ? ④通常情況下，我們應當遵守單一職責原則，只有邏輯足夠簡單，才可以在代碼級別違反單一職責原則，只有類中方法數量足夠少，可以在方法級別保持單一職責原則。

?

接口隔離原則（interface segregation principle）

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

?

依賴倒轉原則(dependence inversion principle)

? ①高層模塊不應該依賴低層模塊，二者都應該依賴其抽象。

? ②抽象不應該依賴細節，細節應該依賴抽象。

? ③依賴倒轉的中心思想是面向接口編程。

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

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

? ?依賴關系傳遞的三種方式1.接口傳遞 ? 2. 構造方法傳遞 ?3. setter方法傳遞。

里式替換原則(Liskov Substitution?Principle)

? ? ①所有引用基類的地方必須能透明地使用其子類的對象

? ? ?②在使用繼承時候，遵循里式替換原則，在子類中盡量不要重寫父類的方法。

? ? ③里式替換原則告訴我們，繼承實際上讓兩個類耦合性增強了，在適當的情況下，可以通過聚合，組合，依賴來解決問題。

? oo中的繼承性的思考和說明：

? ? ?①繼承包含這樣一層含義，父類中凡是已經實現好的方法，實際上是在設定規范和契約，雖然它不強制要求所有的子類必須遵循這些契約，但是子類如果對這些已經實現的方法任意修改，就會對整個繼承體系造成破壞。

? ?②繼承在給程序設計帶來便利的同時，也帶來了弊端，比如使用繼承會給程序帶來侵入性，程序的可移植性降低，增加對象間的耦合性，如果一個類被其他的類所繼承，則當這個類需要修改時，必須考慮到所有的子類，并且父類修改后，所有涉及到子類的功能都有可能產生故障。

? ?那么如何正確使用繼承呢？ 遵循里式替換原則。

開閉原則(open closed principle)

? ?①?編程中最基礎，最重要的設計原則。

? ?②一個軟件實體如類，模塊和函數應該對擴展開放(對提供方)，對修改關閉(對使用方)。用抽象構建框架，用實現擴展細節。

? ?③當軟件需要變化時，盡量通過擴展軟件實體的行為來實現變化，而不是通過修改已有的代碼來實現變化。

? ?④編程中遵循其他原則，以及使用設計模式的目的就是遵循開閉原則。

迪米特法則

? ?① 一個對象應該對其他對象保持最少的了解

? ?②類與類關系越密切，耦合度越大

? ?③迪米特法則(Demeter Principle) 又叫最少知道原則，即一個類對自己依賴的類知道的越少越好，也就是說，對于被依賴的類不管多么復雜，都盡量將邏輯封裝在類的內部，對外除了提供的public方法，不對外泄漏任何信息。

? ?④迪米特法則還有個更簡單的定義，只與直接的朋友通信。

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

合成復用原則

? 盡量使用合成/聚合的方式,而不是使用繼承。

?

代碼重用性(相同的代碼，不用多次編寫)

代碼可讀性

總結

以上是生活随笔為你收集整理的设计模式:设计模式七大原则的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。