淺談依賴倒置原則
前言
我們工作中經常用到優秀的框架和工具，他們爲什麼優秀，知其然了其精髓能對我們起到更多的幫助。好的框架應該讓使用者感受不到他的存在，而能爲其提供很多的功能。客戶程序在框架內可以任意實現自己的業務邏輯代碼， 而好的框架應該完全能支持纔對。這就是工具和框架的區別，工具是爲客戶提供了某些能力，客戶去主動調用，而框架是爲客戶程序提供了一種固有模式約束，由客戶程序來按照約定好的的模式邏輯來實現，框架把按照框架架構所約束的模式實現的所有程序統一提供了框架所具有的功能支持。
從上可以看出，框架和工具的主要區別是在框架中客戶程序把實現的具體控制權上交上去了，使具有高層決定性作用的框架功能不會依賴於客戶程序的實現。這就是我們今天的正題了依賴倒置。
依賴倒置
Hollywood原則？什麼是依賴倒置
引用<<敏捷軟件開發>>中一言，一個設計良好的面向對象的程序，其依賴程序相對於傳統的過程式方法設計的通常結構而言就是被倒置了。依賴倒置是”松耦合“ 設計的很好體現，高層模塊不直接依賴低層的實現，而是依賴於低層模塊的抽象。高層模塊不應該依賴於低層模塊，二者應該依賴於抽象。而抽象不應該依賴於細節，細應該依賴於抽象。
這段話很拗口，簡單點通俗來講，比如一個A 依賴於 B，如果A 需要實現另外的功能，需要依賴於B的具體改動才能完成，這就增加了兩者之家的耦合性。這時如果A與B之間增加一個C來承接A的抽象實現，A與B之間就不具備很強的依賴關係了。這樣A就把對B的依賴控制在了手裏，A不在依賴於B，而B卻需要依賴A的功能抽象類C。這也是註明的Hollywood原則，”Don’t call us，we call you“，底層模塊實現了在高層模塊中的聲明並被高層模塊調用的接口，導致了接口的所有權。
依賴於抽象，程序中所有的依賴關係都應該終止與抽象類或者接口
一個稍微簡單但仍然非常有效的對於DIP的解釋：”依賴於抽象“。程序中所有的依賴關係都應該終止於抽象類或者接口。
- 任何變量都不應該持有一個指向具體類的指針或者引用
- 任何類都不應該從具體類派生
- 任何方法都不應該複寫他的任何基類中的已經實現了的方法
當然每個程序中都會有違反該啓發規則的情況。
依賴倒置放置在哪？
我們只聊依賴倒置，軟件的設計，但是難免又會涉及到了軟件的分層結構。傳統的大部分公司我們都在使用分層架構，簡單的三層架構會使得面向對象的特點一點點在工作中蒸發。controller、service、dao基本決定了大部分應用場景的模型，service層中通常會用來定義抽象與抽象接口的實現，雖然上層會使用抽象調用業務具體實現，但是按照上文中依賴倒置原則的劃分，分包邏輯卻似乎不正確。
區別於傳統分層模型的另一種軟件設計思想是領域驅動設計（DDD，這篇不做過分涉及），在DDD中嚴格約束下層對象不能調用上層，其中傳統的DDD四層模型會有用戶接口層、應用層、領域層、基礎設施層，我們拿領域層的一處實現來說，領域層中會有實體、值對象、事件、領域服務、資源庫等，在這裏資源庫負責DAO層處理，這裏提出好的意思是，我們可以把抽象層單獨分包爲獨立的一層facade層負責處理業務的抽象，具體的實現我們可以單獨抽離爲persistence負責業務的實現處理，這樣雖然看起來和三層分層結構沒有區別，但是從意義上我們更貼近了依賴倒置，後續也會使得擴展更簡單。
接口可以被許多不同的客戶使用，並被許多不同的服務者實現。這樣我們接口就放置在了一個單獨的組中去控制依賴倒置的關係。