設計模式六大設計原則（三）：依賴倒置原則

1、定義

High level modules should not depend upon low level modules.Both should depend upon abstractions.Abstractions should not depend upon details.Details should depend upon abstractions.（高層模塊不該該依賴低層模塊，二者都應該依賴其抽象。 抽象不該該依賴細節。 細節應該依賴抽象）

用JAVA語言來闡述的話意思是約束了：

• 模塊間的依賴經過抽象發生，實現類之間不發生直接的依賴關係，其依賴關係是經過接口或抽象類產生的
• 接口或抽象類不依賴於實現類
• 實現類依賴接口或抽象類

2、優勢與限制

這不就是咱們常聽到的面向接口編程嗎，其中的好處不言自明。但我仍是簡單總結下把：

（一）優勢

• 減小類間的耦合性，由於模塊間的依賴變爲了經過接口的方式，模塊間調用依賴具體類變爲了依賴接口，而接口更加抽象。
• 提升系統的穩定性，由於接口是具體類職責的抽象出的相對穩定的部分。
• 下降並行開發引發的風險，先定義接口職責，各模塊能夠經過接口來並行開發。
• 提升代碼的可讀性和可維護性，減小耦合，天然可讀性可維護性就提升了。

（二）限制

• 對於一個業務需求來講，並非都能抽象出一個接口，若是強行抽象出接口，這個接口的複用性也不會很高。由於這個業務在這裏的聯繫原本就是依賴於具體細節的。因此有時候咱們看到WEB開發中，有些單體項目並不會爲Service層定義接口，由於在這種項目中，定義接口的複用性也不是很高。

3、建議

• 每一個類儘可能都有接口或抽象類，或者抽象類和接口二者都具有（接口定義職責，抽象類提供默認實現）
• 變量的表面類型儘可能是接口或者是抽象類
• 儘可能不要從具體類派生類
• 儘可能不要覆寫基類已經實現的方法
• 結合里氏替換原則使用，意思就是說類實現時不要破壞抽象的職責定義