設計模式 依賴倒轉原則

依賴倒轉原則又稱依賴倒置原則：

抽象不應該依賴細節，細節應該依賴於抽象。說白了，就是針對介面程式設計，不要針對實現程式設計。

1)高層模組不應該依賴低層模組，兩者都應該依賴其抽象；

2)抽象不應該依賴細節;

3)細節應該依賴抽象。

1)為什麼要針對介面程式設計，而不是針對實現程式設計呢？

很簡單的乙個例子，我們現在使用的電腦有各式的品牌，聯想、神舟、戴爾等等，

電腦需要用到滑鼠，鍵盤；假設滑鼠、鍵盤是針對某乙個品牌的機器實現去做的話，那麼我們將會遇到什麼問題呢？

那麼我們市面上的鍵盤和滑鼠就都是各式各樣的，有一天滑鼠，或鍵盤壞了，我們要怎麼去買呢？難道記住這個電腦是什麼品牌，什麼型號，還有什麼型別的去買麼？這樣會瘋掉的。現在我們的電腦基本上都是使用usb介面的了，無論是鍵盤也好，滑鼠也好，我們只要買usb介面的就可以使用了，同時，使用usb介面還可以有其他的擴充套件，只要實現了，這個介面，實現怎麼樣都沒關係，例如，實現了usb介面的小檯燈，只要接上usb線就可以照明了；又如實現了usb

介面的充電器，接到我們的電腦上就可以充電了。 

在面向過程的開發中，為了使用常用的**可以復用，一般都會把這些常用的**寫成許許多多函式的程式庫，這樣我們做新專案的時候，就去呼叫這些函式就可以了。

例如：我們做的專案大多要訪問資料庫，所以我們就把資料庫的**寫成了函式，每次做新專案時就去呼叫這些函式，這也就是高層依賴於低層模組了。

問題就出現在這裡了，我們在做新專案的時候，會發現業務邏輯的高層模組是一樣的，我們希望能重用這些高層模組，但是這些高層模組和低層模組的資料庫繫結在一起了，這樣我們就沒辦法復用這些高層模組了。

如果我們的高層模組和低層模組都依賴於抽象，具體一點就是依賴於介面或抽象類，只要介面夠穩定，那麼任何乙個的更改都不用擔心其他受到影響了。

黎克特制替換原則：

乙個軟體實體如果使用的是乙個父類的話，那麼一定適用於其子類，而且它察覺不出父類物件和子類物件的區別。也就是說，在軟體裡面，把父類都替換成它的子類，程式的行為沒有變化；

簡單的說：子型別必須能夠替換掉它們的父型別。例如：企鵝在生物學分類上是屬於鳥的，但是在程式設計中，企鵝就不能以父類的(鳥)的身份出現。

假設有乙個鳥的父類，擁有乙個會飛的方法fly()，我們是不能讓企鵝繼承於鳥的，這樣當子類可以替換掉父類，軟體單位的功能不受到影響時，父類才能真正的被復用，

而子類也能夠在父類的基礎上新增新的行為。例如：貓是繼承動物類的，以動物的身份擁有吃、喝、跑、叫等行為，

可當某一天，我們需要狗、牛、羊也擁有類似的行為，由於它們都是繼承於動物，所以除了更改例項化的地方，程式其他地方就需要改變了。

正是由於子型別的可替換性才使得使用父類型別在的模組在無需修改的情況下就可以擴充套件。uml圖：

高層模組依賴於介面或抽象類，低層模組實現介面或抽象類。依賴倒置原則其實就是誰也不依靠誰，除了約定的介面，這樣大家都可以靈活自由了。

設計模式 依賴倒轉原則

依賴倒轉原則解釋 抽象不應該依賴於細節，細節應該依賴於抽象。說通俗點也就是針對介面程式設計，不要針對實現程式設計。我們在做開發的時候，要訪問資料庫，就會把訪問資料庫的 寫成函式，每次去開發的時候呼叫這些函式就行了，其實這就叫高層模組依賴底層模組，違反了依賴倒轉原則。當我們做乙個新專案的時候，發現業務...

設計模式 依賴倒轉原則

include using namespace std class benz boss bmw bmw void drivebenz void drivebmw private benz benz bmw bmw 此時若老闆還想開寶馬，必須還要再有乙個bmw bmw私有變數，還要定義相應的建構函式和...

設計模式原則 依賴倒轉原則（三）

依賴倒轉原則解釋 抽象不應該依賴於細節，細節應該依賴於抽象，說通俗點也就是針對介面程式設計，不要針對實現程式設計.我們在做開發的時候，要訪問資料庫，就會把訪問資料庫的 寫成函式，每次去開發的時候呼叫這些函式就行了，其實這就叫高層模組依賴低層模組，違反了依賴倒轉原則 當我們做乙個新專案的時候，發現業務...