依賴倒置原則: 一般來說我們認為作為底層基礎框架的邏輯是不應該依賴於上層邏輯的, 所以我們設計軟體時也經常是: 需求 - 上層邏輯(直接實現需求) - 發現需要固化的邏輯 - 開發底層模塊 - 然後上層調用底層邏輯. 但是這樣做一開始是沒問題的, 但是當上層劇烈變化時, 會不斷的侵染底層邏輯, 底層 ...
依賴倒置原則:
一般來說我們認為作為底層基礎框架的邏輯是不應該依賴於上層邏輯的, 所以我們設計軟體時也經常是:
需求 - 上層邏輯(直接實現需求) - 發現需要固化的邏輯 - 開發底層模塊 - 然後上層調用底層邏輯.
但是這樣做一開始是沒問題的, 但是當上層劇烈變化時, 會不斷的侵染底層邏輯, 底層邏輯雖然變動不大, 但是一旦變化, 成本極其高, 因為它要影響所有依賴於它的上層邏輯. 萬一你改一個介面, 又不能相容舊的方式. 除了引入適配器這種中間膠水層
別無他法, 但是這種膠水層如果不斷變厚, 出現的更加頻繁, 那麼上層/膠水層/底層 的界限徹底的模糊. 維護是一個災難. 所以膠水層的出現一般就意味著底層和上層邏輯出現了分歧. 底層設計需要適應變化.
一般來說應該儘力的避免膠水層的存在,至少要限制其發展, 不能變厚.(UNIX 編程藝術 Page 97)
在高層具體邏輯驅動的底層開發方式中. 底層的設計思路往往會被具體業務嚴重限制, 導致底層變成了特定上層的底層,失去通用性, 難以長期穩定. 大到整體方案的重新選擇, 換個資料庫, 換個OS平臺? 小到一個介面的參數變化, 甚至命名的修改.
都會導致之前的工作無法有效繼承延續下去, 導致工作內容無法復用. 大量工作付諸東流.
因此底層的開發千萬不能由高層具體邏輯驅動, 那如何去做? 這就是依賴倒置原則的價值所在 !
既然底層不能依賴上層, 那麼我們之前的設計思路就會出現問題, 在得到需求後首先設計上層就是問題的源泉. 那我們要從何處入手?
依賴倒置原則講求的是: 上層不應該依賴於底層, 而是上層和底層都應該依賴於抽象. 或者說. 不要依賴任何具體類, 只依賴於抽象.
這裡其實指明瞭一個道路. 都應該依賴於抽象, 也就是接到需求的第一步是設計抽象, 然而抽象什麼? 這需要從依賴倒置最難理解的一部分說起: 倒置是什麼?
依賴倒置, 我們可能會認為, 既然上層依賴底層是不對的, 那倒置了就是底層依賴上層? 這一點也是困惑的, 上層變化那麼快, 底層不得瘋掉?
所以依賴倒置這裡和 "針對介面編程, 不針對具體實現編程" 的區別就在於: 這裡是更加強調抽象, 強調依賴抽象去編程.
在頻繁變化的需求下, 抽象是更加穩定的概念, 因此花更多的心思設計各層的抽象, 做到在一層之內做"具體依賴抽象",在各層之間做"抽象依賴抽象", 只有這樣系統才會更加穩定和健壯.
所以倒置的依賴不是指向了具體的上層, 而是一個抽象的上層. 這裡回到剛剛提出的問題, 我們從何處入手? 不是從具體的上層, 也不是底層, 而是抽象,並且是抽象的上層.
所以這裡 倒置的是依賴, 依賴的是抽象, 抽象的是上層. 這三句話即是依賴倒置的步驟.
當然, 依賴倒置說的是不依賴具體,而依賴於抽象的上層, 這裡是上層又可以做文章, 上層的抽象是"抽象的上層", 底層的抽象也是"抽象的上層". 所以很多地方畫依賴倒置的圖
有兩個抽象類, 一邊是對上層的抽象, 一邊是對底層的抽象, 而抽象依賴抽象, 各自的"下層" 依賴各自的抽象. 形成一個橋型結構.
這兩個抽象, 是我們需要首先深思熟慮的設計的.
這樣是不是一切豁然開朗.
說到了這裡, 或許還需要一個標準, 如何不違反依賴倒置原則:
1. 變數不持有任何具體類的引用 -> 持有抽象. 可以通過工廠+類族避免
2. 不要讓類派生自任何具體類 -> 具體類是類族上一個具體的葉子節點, 依賴於葉子節點有兩個可能: 他們是很像的兄弟. 單純為了共用代碼. 這兩種情況, 不要偷懶, 考慮抽象一個父節點(介面,抽象類)掛上面
3. 不要覆蓋基類中已經實現的方法 -> 如果你覆蓋了, 那這個基類就失去了它的權威性, 這個被重寫的函數大概蘊含著一個分支的類族. 如果一個類的很多有實現的方法被如此覆寫, 那這個類就是一個被子彈打成篩子的容器
那麼, 結合上面三點, 你回顧下自己的代碼, 是否感覺非常可怕(或者不可思議,不太可能)
設計模式的運用並不是一成不變,固守陳規. 在上述三個原則中, 是我們設計的標尺, 具體要視情況而定, 如果有更強烈的理由, 也可以打破這種限定. 所有的設計模式都是指導性的思想而並不是程式的評判標準.
有很多設計模式的思想,希望我們追求抽象, 希望我們消除if-else switch.但是這些思想都需要我們增加很多的類, 很多的繼承關係. 造成了類的爆炸. 凡事必有一個度和界限. 設計亦是如此.
為了高可維護性, 高復用度去做的事情, 做的過分了就會出現邊際效用遞減的情況, 出現副作用, 弊大於利的情況.
這裡設計做到什麼程度的衡量標準用一個經典的話來說就是: 避免過渡設計, 避免提前設計.
上面說的兩個抽象類, 也是視複雜度設計為一個或者兩個.
參考資料: HeadFirst 設計模式 Page: 139
喜歡這本書的原因就在於, 你的疑問, 他想得到還會立馬給你解惑.
https://mp.weixin.qq.com/s/Kd1T40KZWvdThKC3IN6n-Q
優秀的架構師應該能在上述三角形張力區域中定位一個最適合目前研發團隊狀態的位置，例如在項目早期，CCP比REP更重要，隨著項目的發展，這個最合適的位置也要不停調整。
