本篇介紹軟體設計原則之一DIP：依賴倒置原則。很多知識回頭來看會有新的理解。看到一句話，一段文字，一個觀點有了新的理解，醍醐灌頂的感覺。這種感覺像是一種驚喜。古語說：溫故而知新。
DIP：依賴倒置原則
a.高層模組不應該依賴於低層模組。二者都應該依賴於抽象。
b.抽象不應該依賴於細節。細節應該依賴於抽象。
層次化
Booch曾經說過：“所有結構良好的物件導向架構都具有清晰的層次定義，每個層次通過一個定義良好的、受控的介面向外提供了一組內聚的服務”
倒置的介面所有權
這裡的倒置不僅僅是依賴關係的倒置，它也是介面所有權的倒置。我們通常會認為工具庫應該擁有它們自己的介面。但是當應用了DIP時，我們發現往往是客戶擁有抽象介面，而它們的服務者從這些抽象介面派生。
依賴於抽象
該啟發式規則建議不應該依賴於具體類——也就是說應該終止於抽象類或介面。
我們在應用程式中所編寫的大多數的類是不穩定的。我們不想直接依賴於這些不穩定的具體類。通過把它們隱藏在抽象介面的後面，可以隔離它們的不穩定性。但這不是一個完整的解決方案，常常，如果一個不穩定的介面必須要變化時，這個變化一定會影響到表示該類的介面。這種變化還是破壞了由抽象介面維繫的隔離性。如果看得更遠一些，認為是由客戶模組或層來宣告它們需要的服務介面，那麼僅當客戶需要時才會對介面進行改變。這樣，改變實現抽象介面的類就不會影響到客戶。
那麼我們來聊下我們應用中常用的架構型別，微軟為了展示.Net企業系統開發的能力。曾經發布過一個PetShop作為範例，後來很多企業系統的架構都採用了參照了或簡化了此架構設計。標準的三層架構。
從上圖所知，業務層對資料訪問層抽象出來的IDAL模組，除了解除了向下的依賴之外，對於其上的業務邏輯層，相同僅存在弱依賴關係。那麼來看這個設計滿足了DIP：依賴倒置原則的高層模組不應該依賴於低層模組，二者都應該依賴於抽象。 傳統的軟體開發，比如結構化分析和設計，總是傾向於建立一些高層模組依賴於低層模組、策略依賴於細節的軟體結構。實際上這些方法的目的之一就是要定義子程式層次結構，該層次結構描述了高層模組怎麼呼叫低層模組。一個設計良好的物件導向程式（如上圖所示的Petshop ),其依賴程式結構相當於傳統的過程式方法設計的通常結構而言就是被“倒置“了。
那麼IDAL介面層的所有權屬於誰的？以前一直有這個疑問直到看到這一章疑問解決了。通常認為IDAL介面層屬於DAl層，那是不對的。這裡的IDAL介面層的所有權是屬於BLL層了，介面所有權倒置了。通過倒置這些依賴關係，我們建立了一個更靈活、更持久、更易改變的結構。高層模組BLL不在直接依賴DAL層，而依賴抽象IDAL介面層。則層與層之間的關係就是鬆散耦合的。假設此時必須要改動資料訪問層的實現，僅僅重新實現IDAL的介面定義，那麼業務邏輯層就不會受到影響。畢竟，無論是SQLServerDAL還是OracalDAL與業務邏輯層實現沒有直接的關係。
面象物件的程式設計倒置了依賴關係，使得細節和策略依賴於抽象，並且常常是客戶擁有服務介面。依賴關係的倒置正是好的物件導向設計的標誌所在。是實現許多物件導向技術所宣稱的好處的基本低層機制。它的正確應用對於建立重用的框架來說是必需的。同時它對於構建在變化面前富有彈性也是重要的。由於抽象和細節彼此隔離，所以程式碼也非常容易維護。
其實最深的體會是對介面所有權倒置的理解。
程式碼示例地址：https://github.com/tianyaxiang/ApplicationArchitecture
本文首發於個人微信公眾號：webguan ；歡迎您的關注
