軟件開發中需要知道基本概念，由羅伯特·C·馬丁（Robert C. Martin）于《敏捷軟件開發：原則、模式和實踐》一書中給出的。在此記錄。

目錄

一.單一職責原則

二.開放封閉原則

三.?里氏替換原則

四.接口分離原則

五.依賴倒置原則

---

---

一.單一職責原則

一個類，只有一個引起它變化的原因。應該只有一個職責。每一個職責都是變化的一個軸線，如果一個類有一個以上的職責，這些職責就耦合在了一起。這會導致脆弱的設計。當一個職責發生變化時，可能會影響其它的職責。另外，多個職責耦合在一起，會影響復用性。

如果一個類承擔的職責過多，就等于把這些職責耦合在一起了。一個職責的變化可能會削弱或者抑制這個類完成其他職責的能力。這種耦合會導致脆弱的設計，當發生變化時，設計會遭受到意想不到的破壞。而如果想要避免這種現象的發生，就要盡可能的遵守單一職責原則。此原則的核心就是解耦和增強內聚性。

問題理解

T負責兩個不同的職責：職責P1，職責P2。當由于職責P1需求發生改變而需要修改類T時，有可能會導致原本運行正常的職責P2功能發生故障。也就是說職責P1和P2被耦合在了一起。

解決辦法

遵守單一職責原則，將不同的職責封裝到不同的類或模塊中。

二.開放封閉原則

關于開放封閉原則，其核心的思想是：

軟件實體應該是可擴展，而不可修改的。也就是說，對擴展是開放的，而對修改是封閉的。

因此，開放封閉原則主要體現在兩個方面：

對擴展開放，意味著有新的需求或變化時，可以對現有代碼進行擴展，以適應新的情況。

對修改封閉，意味著類一旦設計完成，就可以獨立完成其工作，而不要對類進行任何修改。

“需求總是變化”、“世界上沒有一個軟件是不變的”，這些言論是對軟件需求最經典的表白。從中透射出一個關鍵的意思就是，對于軟件設計者來說，必須在不需要對原有的系統進行修改的情況下，實現靈活的系統擴展。而如何能做到這一點呢？

只有依賴于抽象。實現開放封閉的核心思想就是對抽象編程，而不對具體編程，因為抽象相對穩定。讓類依賴于固定的抽象，所以對修改就是封閉的；而通過面向對象的繼承和對多態機制，可以實現對抽象體的繼承，通過覆寫其方法來改變固有行為，實現新的擴展方法，所以對于擴展就是開放的。這是實施開放封閉原則的基本思路，同時這種機制是建立在兩個基本的設計原則的基礎上，這就是Liskov替換原則和合成/聚合復用原則。

三.?里氏替換原則

里氏替換原則(Liskov Substitution Principle LSP)面向對象設計的基本原則之一。 里氏替換原則中說，任何基類可以出現的地方，子類一定可以出現。 LSP是繼承復用的基石，只有當衍生類可以替換掉基類，軟件單位的功能不受到影響時，基類才能真正被復用，而衍生類也能夠在基類的基礎上增加新的行為。

• 子類必須實現父類的抽象方法，但不得重寫（覆蓋）父類的非抽象（已實現）方法。
• 子類中可以增加自己特有的方法。
• 當子類覆蓋或實現父類的方法時，方法的前置條件（即方法的形參）要比父類方法的輸入參數更寬松。
• 當子類的方法實現父類的抽象方法時，方法的后置條件（即方法的返回值）要比父類更嚴格。

四.接口分離原則

接口分離原則指在設計時采用多個與特定客戶類有關的接口比采用一個通用的接口要好。即，一個類要給多個客戶使用，那么可以為每個客戶創建一個接口，然后這個類實現所有的接口；而不要只創建一個接口，其中包含所有客戶類需要的方法，然后這個類實現這個接口。

如果不使用接口分離：

?如果Client A類需要改變所使用的Service接口中的方法，那么不但要改動Service接口和ServiceImp類，還要對ClientB類和ClientC類重新編譯。

五.依賴倒置原則

依賴倒置原則（Dependence Inversion Principle）是程序要依賴于抽象接口，不要依賴于具體實現。簡單的說就是要求對抽象進行編程，不要對實現進行編程，這樣就降低了客戶與實現模塊間的耦合。

面向過程的開發，上層調用下層，上層依賴于下層，當下層劇烈變動時上層也要跟著變動，這就會導致模塊的復用性降低而且大大提高了開發的成本。

面向對象的開發很好的解決了這個問題，一般情況下抽象的變化概率很小，讓用戶程序依賴于抽象，實現的細節也依賴于抽象。即使實現細節不斷變動，只要抽象不變，客戶程序就不需要變化。這大大降低了客戶程序與實現細節的耦合度。

百度上有一個代碼示例：例子

總結

以上是生活随笔為你收集整理的面向对象五个基本原则的全部內容，希望文章能夠幫你解決所遇到的問題。

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