dependency inversion principle

高層次的模組不應該依賴 於 低層次的模組，兩者都應該依賴於 抽象介面。

程式碼的設計，就應該像作業系統的設計，高層次的模組，比如APP，不依賴於這個系統是linux 還是windows的具體實現，而僅僅依賴於作業系統這個抽象介面，這樣的話，APP業務邏輯的更迭，完全不用費心去考慮，面對不同的作業系統的具體實現，我們要做什麼適配，這個為了適配不同平臺的考慮完全是浪費精力，效率也低。所以，我們要設計一個模組，向外提供一個抽象的介面，那麼外部的模組就容易和我們配合。

抽象的介面不應該依賴於具體的實現，而具體的實現依賴於抽象的介面

這個可能和我們常見的【熟能生巧】成為反比，平時我們設計了很多具體實現，才慢慢發現，其中的道，於是後來就抽象出來一種靈巧的方式，完成我們的工作；

但是在快速，協作的開發環境中，我們最好的方式是： 先抽象好，再去落地具體實現。

總結：

我們設計抽象介面的時候，不應該是憑藉眾多具體的實現，再慢慢提取出一個現有眾多實現的一個抽象，而是我們先提出一個約定，也就是先提出一個抽象的介面，（這個介面可能不能滿足具體實現的某個功能，但是介面隔離原則允許我們這樣做），然後我們再根據這個抽象介面去設計具體的實現；這樣做的好處就是，我們後期只需要面對一個單獨的抽象介面進行業務的更迭，變化，而不用去考慮業務的改變對已有程式碼的具體實現的影響。具體的實現在約定的框架下做任何變動，不會影響更上層的設計。