面試常遇到的問題，雖然都懂但臨時要講出來還真不好講，所以用自己的話寫一遍
我們為了要達到各模組間或各種物件間鬆散耦合的目標，
就必須調整這之間的依賴關係，傳統寫程式是高階模組依賴低階模組，
你會在某個 method 中 new 個 物件，然後執行裡面方法，
這樣就是高依賴低，若系統變大了，低階的實作方法又必須更換或調整時，工就多了，
除了要新實作低階方法，依賴它的各個模組也有可能要一併調整，
另一方面有沒有可能不靠依賴倒置，直接認定這個低階實作一定涵蓋所有未來可能的變動， 在下覺得當然不無可能，但就要在需求分析設計階段多下苦功了，但為了以鬆散耦合為目標，我覺得還是 follow 比較好。
為了改善此現象，所以具體做法會是高階程式依賴抽象，低階的實作也依賴抽象，
這時就是反轉了依賴關係，低階實作必須要依賴抽象層，
這時高階實作的調整幅度會達到最小化的調整甚至不需調整，
具體範例可以想像 儲存資料在硬碟位置或直接儲存至DB 實作同一 interface 的方法 但實作內容不同。
依賴倒置是倒置依賴關係，控制反轉是反轉控制流程（對被依賴低階實例的控制權），
一般程式對依賴的物件有主動控制權，雖然透過依賴倒置精神，可以改變依賴抽象，
但程式上還是必須自己 new 出 instance，也就是程式對依賴的控制流程有主導權，
這樣更換低階實作，也是必須去調整高階模組 new xxx()，
為了要更加解耦，就該把控制流程反轉，也就是高階模組不主動去 new 這 instance，
而是利用 DI 或 工廠模式去被動取得 instance ，這樣就達到解耦效果，
高階模組再也不必管會得到什麼 instance ，而是IOC容器透過設定檔知道程式需要這個 instance，
並給它，以達到不需要修改高階模組為目的。
程式在執行期間需要依賴的物件由容器IOC容器直接注入給程式，利用的是反射原理，
把預先設定好的 bean 透過 spring beanFactory 做 init、destory 等，
程式不必理會物件是如何產生、保持、至銷毀的生命週期，基本上 instance 也是 singleton 的，
產生後就一直 keep 住，重複使用，減少系統運行的負擔，
完美的發揮 IOC 精神。
以上是個人淺見，有錯還請不吝指教