設計原則--《架構整潔之道》讀書筆記

• 前言
• 一、SRP：單一職責原則
• 二、OCP：開閉原則
• 三、LSP：里氏替換原則
• 四、ISP：接口隔離原則
• 五、DIP：依賴反轉原則
• 六、總結

---

前言

???????? 通常來說，要想構建一個好的軟件系統，應該從寫整潔的代碼開始做起。畢竟，如果建筑所使用的磚頭質量不佳，那么架構所能起到的作用也會很有限。反之亦然，如果建筑的架構設計不佳，那么其所用的磚頭質量再好也沒有用。這就是SOLID設計原則所要解決的問題。這篇博文是對SOLID設計原則的簡單讀書筆記，簡述這些原則的一些基本知識，希望對大家有幫助。
SRP：單一職責原則
OCP：開閉原則
LSP：里氏替換原則
ISP：接口隔離原則
DIP：依賴反轉原則

---

一、SRP：單一職責原則

????????SRP是SOLID五大設計原則中最容易被誤解的一個。也許是名字的原因，很多程序員根據SRP這個名字想當然地認為這個原則就是指：每個模塊都應該只做一件事。
????????沒錯，后者的確也是一個設計原則，即確保一個函數只完成一個功能。我們在將大型函數重構成小函數時經常會用到這個原則，但這只是一個面向底層實現細節的設計原則，并不是SRP的全部。
????????SRP描述：任何一個軟件模塊都應該只對某一類行為者負責。（行為者：一個或多個有共同需求的人）

二、OCP：開閉原則

????????開閉原則是Bertrand Meyer在1988年提出的，該設計原則認為：設計良好的計算機軟件應該易于擴展，同時抗拒修改。換句話說，一個設計良好的計算機系統應該在不需要修改的前提下就可以輕易被擴展。
????????軟件架構師可以根據相關函數被修改的原因、修改的方式及修改的時間來對其進行分組隔離，將這些相互隔離的函數分組整理成組件結構，使得高階組件不會因低階組件被修改而受到影響。
????????OCP是我們進行系統架構設計的主導原則，其主要目標是讓系統易于擴展，同時限制其每次被修改所影響的范圍。實現方式是通過將系統劃分為一系列組件，并且將這些組件間的依賴關系按層次結構進行組織，使得高階組件不會因低階組件被修改而受到影響。

三、LSP：里氏替換原則

????????在面向對象這場編程革命興起的早期，我們的普遍認知是，LSP只不過是指導如何使用繼承關系的一種方法，然而隨著時間的推移，LSP逐漸演變成了一種更廣泛的、指導接口與其實現方式的設計原則。
????????LSP可以且應該被應用于軟件架構層面，因為一旦違背了可替換性，該系統架構就不得不為此增添大量復雜的應對機制。

四、ISP：接口隔離原則

????????在一般情況下，任何層次的軟件設計如果依賴于不需要的東西，都會是有害的。從源代碼層次來說，這樣的依賴關系會導致不必要的重新編譯和重新部署，對更高層次的軟件架構設計來說，問題也是類似的。

五、DIP：依賴反轉原則

????????依賴反轉原則主要想告訴我們的是，如果想要設計一個靈活的系統，在源代碼層次的依賴關系中就應該多引用抽象類型，而非具體實現。
????????LSP如果想要在軟件架構設計上追求穩定，就必須使用穩定的抽象接口，少依賴多變的具體實現。
???????? 在軟件架構中，抽象層與具體實現層的邊界叫架構邊界，它將系統劃分為兩個部分組件：抽象接口與其具體實現。抽象接口組件中包含了應用的所有高階業務規則，而具體實現組件中包含了所有這些業務規則所需要做的具體操作及其相關的細節信息。應用程序的控制流跨越架構邊界的反向與源代碼依賴關系跨越該邊界的方向正好相反，源代碼依賴方向永遠是控制流方向的反轉，這就是DIP被稱為依賴反轉原則的原因。
這個設計原則可以歸結為以下幾條具體的編碼守則：
1、應在代碼中使用抽象接口，盡量避免使用那些多變的具體實現類。
2、不要在具體實現類上創建衍生類。
3、不要覆蓋（override）包含具體實現的函數，應該設計為抽象函數。
4、應避免在代碼中寫入與任何具體實現相關的名字，或者是其他容易變動的事物的名字。

六、總結

???????? 在系統架構圖中，DIP通常是最顯而易見的組織原則。我們在設計一個新系統初期，應該嚴格按照SOLID原則，使我們設計的系統結構分明，易于理解、開發、擴展及維護。

總結

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

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