23種設計模式+額外常用設計模式匯總 (持續更新）23種設計模式+額外常用設計模式匯總 (持續更新）

設計模式的七大原則：

單一職責原則SRP(Single Responsibility Principle)
就一個類而言，應該僅有一個引起它變化的原因。

開放-關閉原則OCP(Open-CLosed Principle)
一個軟件的實體應該對擴展開放，對修改關閉。

里氏代換原則（Liskov Substitution Principle)
子類型必須能夠替換他們的基類（父類）。

依賴倒置原則DIP(Dependence Inversion Principle)
要依賴于抽象，不要依賴于具體。

最少知識原則LKP(Least Knowledge Principle)或稱 迪米特法則（LoD）
一個類對于其他類知道的越少越好，就是說一個對象應當對其他對象有盡可能少的了解,只和朋友通信，不和陌生人說話

接口隔離原則（ISP）
使用多個專門的接口比使用單一的功能更多的總接口要好

合成/聚合原則
要盡量使用合成/聚合，而不是繼承關系達到復用的目的

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

所謂單一職責原則就是一個類僅有一個引起它變化的原因。這里變化的原因就是所說的“職責”。如果一個類有多個引起它變化的原因，那么也就意味著這個類有多個職責，再進一步說，就是把多個職責耦合在一起了。

單一職責原則的核心就是控制類的粒度大小、將對象解禍、提高其內聚性，如果遵循單一職責原則將有以下優點：

降低類的復雜度。一個類只負責一項職責， 其邏輯肯定要比負責多項職責簡單得多。

提高類的可讀性。復雜性降低，自然其可讀性會提高。

提高系統的可維護性?？勺x性提高，那自然更容易維護了。

變更引起的風險降低。變更是必然的，如果單一職責原則遵守得好， 當修改一個功能時，可以顯著降低對其他功能的影響。

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

• 所謂開放-閉合原則，指的是，一個類應該對擴展開放，最修改關閉。一般也被簡稱開閉原則，開閉原則是設計中非常核心的一個原則。
• 開閉原則要求的是，類的行為是可以擴展的，而且是在不修改已有代碼的情況下進行擴展，也不必改動已有的源代碼或者二進制代碼。
• 實現開閉原則的關鍵就在于合理地抽象、分離出變化和不變化的部分，為變化的部分留下可擴展的方式，比如，鉤子方法或者是動態組合對象等。
• 這個原則看起來也很簡單。但事實上，一個系統要全部做到遵守開閉原則，幾乎是不可能的，也沒這個必要。適度的抽象可以提高系統的靈活性，使其可擴展、可維護，但是過度的抽象，會大大的增加系統的復雜程度。應該在需要改變的地方應用開閉原則就可以了，而不用到處使用，從而陷入過度設計。

優點：

對軟件測試的影響
軟件遵守開閉原則的話，軟件測試時只需要對擴展的代碼進行測試就可以了，因為原有的測試
代碼仍然能夠正常運行。

可以提高代碼的可復用性
粒度越小，被復用的可能性就越大； 在面向對象的程序設計中，根據原子和抽象編程可以提高
代碼的可復用性。

可以提高軟件的可維護性
遵守開閉原則的軟件，其穩定性高和延續性強， 從而易于擴展和維護

3.里氏代換原則（Liskov Substitution Principle)

子類型(subtype)必須能夠替換它們的基（父）類型。（子類可以以父類的身份出現)。
比如，如果是父類是鳥，鳥會飛。企鵝🐧不會飛，企鵝是鳥嗎？所以企鵝不能繼承鳥這個類。

里氏替換原則是實現開閉原則的重要方式之一。

它克服了繼承中重寫父類造成的可復用性變差的缺點。

它是動作正確性的保證。即類的擴展不會給已有的系統引入新的錯誤， 降低了代碼出錯的可能性。

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

所謂依賴倒置原則，指的是，要依賴于抽象，不要依賴于具體類。要做到依賴倒置，典型的應用應該做到：

• 高層模塊不應該依賴于底層模塊，二者都應該依賴于抽象
• 抽象不應該依賴于具體實現，具體實現應該依賴于抽象
• 一般高層模塊包含對業務功能的處理和業務策略選擇，應該被重用的，是高層模塊去影響底層的具體實現。
• 要針對接口編程，而不是針對實現編程

因此，這個底層的接口與應該由高層提出的，然后由底層實現的，也就是說底層接口的所有權在高層模塊，因此是一種所有權的倒置。

啟示：好的程序應該強內聚，松耦合。
優點：

依賴倒置原則可以降低類間的精合性。

依賴倒置原則可以提高系統的穩定性。

依賴倒置原則可以減少并行開發引起的風險。

依賴倒置原則可以提高代碼的可讀性和可維護性。

5.最少知識原則LKP(Least Knowledge Principle)或稱 迪米特法則（LoD）

這個原則用來指導我們在設計系統的時候，應該盡量減少對象之間的交互，對象只和自己的朋友談話，也就是只和自己的朋友交互，從而松散類之間的耦合。通過松散類之間的耦合來降低類之間的相互依賴，這樣在修改系統的某一個部分的時候，就不會影響其他的部分，從而使得系統具有更好的維護性。

那么哪些對象才能當做朋友呢？

• 當前對象本身
• 通過方法的參數傳遞過來的對象
• 當前對象所創建的對象
• 當前對象的實例變量所引用的對象
• 方法內所創建或者實例化的對象

其根本思想：

• 強調了類之間的松耦合。
• 類之間的耦合越弱，越有利于復用，一個處于弱耦合的類被修改，不會對有關系的類造成波及。
• 信息的隱藏促進了軟件的復用。

優點:

• 降低了類之間的相合度， 提高了模塊的相對獨立性。
• 由于相合度降低， 從而提高了類的可復用率和系統的擴展

6.接口隔離原則（ISP）

接口隔離原則（Interface Segregation Principle）講的是：使用多個專門的接口比使用單一的總接口要好。換而言之，從一個客戶類的角度來講：一個類對另外一個類的依賴性應當是建立在最小接口上的。

過于臃腫的接口是對接口的污染。不提倡使用，也不應該是用Dirt- Interface。
接口隔離原則是為了約束接口、降低類對接口的依賴性，遵循接口隔離原則有以下優點:

將臟腫龐大的接口分解為多個粒度小的接口，可以預防外來變更的擴散， 提高系統的靈活性和可維護性。

接口隔離提高了系統的內聚性，減少了對外交互，降低了系統的藕合性。

如果接口的粒度大小定義合理， 能夠保證系統的穩定性； 但是，如果定義過小，則會造成接口數量過多，使設計復雜化； 如果定義太大，靈活性降低，無法提供定制服務，給整體項目帶來無法預料的風險。

使用多個專門的接口還能夠體現對象的層次， 因為可以通過接口的繼承， 實現對總接口的
定義。

能減少項目工程中的代碼冗余。過大的大接口里面通常放置許多不用的方法，當實現這個接口的時候，被迫設計冗余的代碼。

7.合成/聚合原則(Favor Composition Over Inheritance )

要盡量使用合成/聚合，而不是繼承關系達到復用的目的。

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

總結

以上是生活随笔為你收集整理的『设计模式』开发设计的七大原则，我做人还是挺有原则，那些代码呢？的全部內容，希望文章能夠幫你解決所遇到的問題。

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