【設計模式】——依賴倒轉原則

   通過一段時間對大話設計模式的學習，發現其中有幾個特別基礎的原則，對於這些原則咱們必須有個清楚的認知，才能更好的向下進行咱們的學習內容。其中依賴倒轉原則在後面的一些設計模式中都有涉及，因此感受頗有必要進行學習。

前提：

    電腦壞了，很簡單的經過電話交流，拆下一個內存條，電腦就這樣簡單的被修好了，這樣是否是也太簡單了。。緣由在哪？你們都拆過電腦，在PC端都採用的是易插拔的方式，無論哪個壞了，僅僅更換或修改那一個就能夠了。這個就是面向對象中高內聚，低耦合。CPU你們都在用，卻只有那麼幾個公司在生產，內聚很強，獨自爲產品。CUP和顯卡，內存條之間的聯繫很微弱。不存在其中一個損壞，全部東西都不能使用的現象。它們都是針對接口設計，而不是針對品牌設計。說白了就是不管是哪一個公司生產的，只要接口同樣，你們均可以使用。

何爲依賴倒轉原則？

A、一直在強調高層模塊不該該依賴低層模塊。兩個都應該依賴抽象。

B、抽象不該該依賴細節。細節應該依賴抽象。

    一直在強調抽象不該該依賴細節，細節應該依賴抽象。這是什麼意思？面對對象的程序設計中三大基本特徵：封裝，繼承，多態。我的感受如今所說的依賴倒轉原則就相似於封裝。不是去面對過程實現編程功能，而是針對接口編程。細節應該依賴抽象：提早提供一個接口，須要實現具體的功能，就去封裝一個功能，而後去實現這個接口。抽象依賴細節這個意思就是先作一個功能，而後在去作一個接口實現，如今作的弊端沒有統一的定義，作一個功能，就須要有一個接口去實現。而第一種則是先制定一個規範，而後你們再去針對規範，作事情，去符合規範要求，在實現具體的功能。上述內容都在講述何爲依賴。那爲何要叫倒轉？在PC存在這樣的問題，CUP，內存條等都須要依賴主板，可是主板壞了，其餘的部件都不能用了。這個也不符合咱們需求啊，不能由於一個損壞，形成全體癱瘓啊。咱們的目的是爲更好的複用。其實主板和CUP等內容都是模塊，只不過一個是低層模塊，一個是高層模塊。因此二者以前不該該是依賴關係，而是它們須要依賴抽象。   

   

      

    到如今就涉及到一個新的原則——里氏代換原則。

里氏代換原則

    子類型必須可以替換掉它們的父類型。在軟件裏面，把父類都替換成它的子類，程序的行爲沒有變化。

    就用書中的例子在編程的世界裏，就不能用企鵝來代替鳥類。

             

只有當子類能夠替換掉父類，軟件不受到影響的時候才能真正被複用，而子類也可以在父類的基礎上增長新的行爲。例如動物類，都擁有吃，跑等行爲，因此當咱們須要狗，貓，相似行爲是，繼承於動物時，只須要實例，程序其餘處不須要改變。

                 

 

【總結】

    以前沒有好好看看這些基本的原則，以致於後面再學習別的模式的時候，感受到有些費勁。一步一步走踏實仍是很重要的。這個依賴倒轉原則其實也沒什麼，好好研究一下，就好了。細節依賴抽象，實現最大程度的複用。