在面向物件程式設計中，我們經常處理處理的問題就是解耦，程式的耦合性越低表明這個程式的可讀性以及可維護性越高（假如程式耦合性過高，改一處程式碼通常要對其他地方也要做大量修改，難以維護）。控制反轉(Inversion of Control或IoC)就是常用的面向物件程式設計的設計原則，使用這個原則我們可以降低耦合性。其中依賴注入是控制反轉最常用的實現。

舉個例子：

假如現在有三個Dao實現類A, B, C，分別對應不同的操作，通常我們在業務層對其進行例項化，然後對外提供例項化後的方法。如下所示：

1 public class UserSeviceImpl implentments UserService{
 
2     private UserDao userDao = new  A();    //注意這裡寫死在程式碼裡了，只要呼叫getUser，返回的就是A的getUser方法 
3 　　 
4     public void getUser(){
5         userDao.getUser();
6     }
7 }

可以看到這時候例項化的是A類，是寫死在程式碼裡的，而如果後面我想再呼叫B類中的操作可怎麼辦呢？ 沒錯，這種情況下就需要對業務層上面這段程式碼進行改動了。假如，有成千上萬個Dao實現類，需求每換一次就要修改一次程式碼，可想而知有多痛苦。

於是就有了IOC控制反轉（這裡的控制，本人的理解是對物件建立的控制權）的思想，上面的程式碼是程式主動建立物件，控制權在程式猿手上；而控制反轉後的程式碼應該變成程式被動接受物件，控制權在使用者手上，就像下面這樣。

1 public class UserSeviceImpl implentments UserService{
2     private UserDao userDao;    //注意這裡不再進行例項化了，而是通過提供一個set方法來完成這個工作。
 
3 　　 public void setUserDao(UserDao userDao){  //利用set動態的進行物件的注入
4 　　　　this.userDao = userDao; 
5 　　 }

6     public void getUser(){
7         userDao.getUser();
 
8     }
9 }

於是使用這種方式我們在需求變化後不用再修改業務層的程式碼，使用者直接給setUserDao傳入不同Dao實現類的物件就好，使得系統的耦合性大大降低，程式猿也就可以更加專注在業務的實現上，而不用去管理物件的建立問題啦！這是IOC的原型，也是簡單的入門理解。後續更難的再慢慢學吧~