IOC理論實現
- UserDao介面
public interface UserDao {
void say();
}
- UserDaoImpl實現類
public class UserDaoImpl implements UserDao {
public void say() {
System.out.println("我想使用預設資料庫");
}
}
- UserService介面
public interface UserService {
void say();
}
- 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
控制反轉 控制什麼反轉了? 建立物件的控制權反轉了 以前建立物件的主動權和建立時機由程式把握
現在這種權力
反轉給其他方
了