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