SpringIOC 理論推導

IOC理論實現

1. UserDao接口

public interface UserDao {
    void say();
}

2. UserDaoImpl實現類

public class UserDaoImpl implements UserDao {
    public void say() {
        System.out.println("我想使用默認數據庫");
    }
}

3. UserService接口

public interface UserService {
    void say();
}

4. UserServiceImpl實現類
   

如以上代碼 如果當前業務跟代碼邏輯一樣 沒有任何問題 輸出 我想使用默認數據庫

---

如果后面有需求 我想使用MySQL數據庫Oracle數據庫等等 有一種方法 service實現類多寫幾個 實現MySQL數據庫Oracle數據庫 再調用對應的接口即可 如果有成千上萬個類似的需求 是不是要寫成千上萬個？還有一種 將userDao的引用指向業務想要的 那么如果頻繁修改 業務邏輯代碼也能相對應的改 麻煩不說 且還容易出問題

---

所以 為了解決工作不便 需要轉變一下思路 能不能讓private UserDao userDao動態化 就像我是mysql userDao就是Mysql 我是oracle userDao就是oracle

---

新增MySQL Oracle業務

public class UserMysqlImpl implements UserDao {
    public void say() {
        System.out.println("我想使用Mysql數據庫");
    }
}


public class UserOracleImpl implements UserDao {
    public void say() {
        System.out.println("我想使用oracle數據庫");
    }
}

---

測試

如圖所示 就是這樣一個改動 加了一個set方法 整個代碼邏輯就變得很清楚 需求是什么 我們就傳入什么
以前userDao的控制完全在程序本身 設置的什么 就是什么 沒有可擴展性

---

現在對象的創建或者說需求的實現發生了反轉 程序被動的接收userDao的值 程序不需要知道userDao什么時候創建的 什么時候傳入進來的 只需要把最終的結果返回出來就好了

---

IOC控制反轉 控制什么反轉了? 創建對象的控制權反轉了 以前創建對象的主動權和創建時機由程序把握 現在這種權力反轉給其他方了