在程序設計領域， SOLID（單一功能、開閉原則、里氏替換、接口隔離以及依賴反轉）是由羅伯特·C·馬丁在21世紀早期引入，指代了面向對象編程和面向對象設計的五個基本原則。當這些原則被一起應用時，它們使得一個程序員開發一個容易進行軟件維護和擴展的系統變得更加可能。

1 單一職責原則（SRP）

一個對象應該只包含單一的職責，并且該職責被完整地封裝在一個類中，即又定義有且僅有一個原因使類變更。（甲類負責兩個不同的職責：職責A，職責B。當由于職責A需求發生改變而需要修改類T時，有可能會導致原本運行正常的職責B功能發生故障。也就是說職責A和B被耦合在了一起”）。

2 開放封閉原則（OCP)

實體應該對擴展是開放的，對修改是封閉的。即可擴展(extension)，不可修改(modification)。

eg:

原代碼，不同用戶類型進行不同服務，但是后續每新增不同的用戶類型，只能在下面繼續加判斷代碼。

修改后代碼，用戶實現統一的接口，后續新增用戶類型，只需要新增對應實現類。

3 里氏替換原則（LSP）

一個對象在其出現的任何地方，都可以用子類實例做替換，并且不會導致程序的錯誤。
經典的例子: 正方形不是長方形的子類。原因是正方形多了一個屬性“長 == 寬”。這時，對正方形類設置不同的長和寬，計算面積的結果是最后設置那項的平方，而不是長*寬，從而發生了與長方形不一致的行為。如果程序依賴了長方形的面積計算方式，并使用正方形替換了長方形，實際表現與預期不符。

4 接口隔離原則（ISP）

接口隔離原則表明客戶端不應該被強迫實現一些他們不會使用的接口，應該把胖接口中的方法分組，然后用多個接口替代它，每個接口服務于一個子模塊。簡單地說，就是使用多個專門的接口比使用單個接口要好很多。

ISP的主要觀點如下：

1）一個類對另外一個類的依賴性應當是建立在最小的接口上的。

ISP可以達到不強迫客戶（接口的使用方法）依賴于他們不用的方法，接口的實現類應該只呈現為單一職責的角色（遵循SRP原則）

ISP還可以降低客戶之間的相互影響---當某個客戶要求提供新的職責（需要變化）而迫使接口發生改變時，影響到其他客戶程序的可能性最小。

2）客戶端程序不應該依賴它不需要的接口方法（功能）。

客戶端程序就應該依賴于它不需要的接口方法（功能），那依賴于什么？依賴它所需要的接口。客戶端需要什么接口就是提供什么接口，把不需要的接口剔除，這就要求對接口進行細化，保證其純潔性。

5 依賴倒置原則（DIP）

抽象不應該依賴于細節，細節應當依賴于抽象。換言之，要針對抽象（接口）編程，而不是針對實現細節編程。

開閉原則（OCP）是面向對象設計原則的基礎也是整個設計的一個終極目標，而依賴倒置原則（DIP )則是實現OCP原則的一個基礎，換句話說開閉原則（OCP）是你蓋一棟大樓的設計藍圖，那么依賴倒置原則就是蓋這棟大樓的一個鋼構框架。

來看一個例子假設我們在開發一個軟件產品需要一個日志系統，要將系統產生的一些重要事情記錄在記事本上。通常我們的實現如下：

但是隨著時間的推移，產品做的好買了很多客戶，產品變得越來越大，使用Logger 類的地方成千上萬處，可怕的事情終于發生了：

A 客戶提出來我想把日志存在數據庫中便于做統計分析。

B 客戶說我想把日志打印在一個控制臺上便于我時時監測系統運行情況。

C 客戶說我要把日志存到Windows Azure Storage上。

怎么辦呢？ 回過頭來看看我們的這個日志系統的設計才恍然大悟：沒有遵守面向對象設計原則的依賴倒置原則和開閉原則了。知道就好，找到法門了， 我們將日志這一塊的設計重構一下讓其符合OCP和DIP應該就可以了。 那么我們就要首先抽象寫日志的接口ILog， 讓實際調用的地方調用高層抽象（ILog），具體的實現類TextLogger，ConsoleLogger，DatabaseLogger，AzureStorageLogger都繼承自ILog接口，然后我們在利用反射加配置，不同的用戶配置不同的具體實現類，這樣問題就迎任而解了。

創作挑戰賽新人創作獎勵來咯，堅持創作打卡瓜分現金大獎

總結

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

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