1.1 分析實現

我們先用我們原來的方式寫一段程式碼 .

1、先寫一個UserDao介面

public interface UserDao {
    public void getUser();
}

2、再去寫Dao的實現類

public class UserDaoImpl implements UserDao {
    @Override
    public void getUser() {
        System.out.println("獲取使用者資料");
    }
}

3、然後去寫UserService的介面

public interface UserService {
    public void getUser();
}
 

• 4、最後寫Service的實現類

public class UserServiceImpl implements UserService {
    private UserDao userDao = new UserDaoImpl();
 
    @Override
    public void getUser() {
        userDao.getUser();
    }
}

5、測試一下

@Test
public void test(){
    UserService service = new UserServiceImpl();
    service.getUser();
}
 

這是我們原來的方式 , 開始大家也都是這麼去寫的對吧 . 那我們現在修改一下 .

把Userdao的實現類增加一個 .

public class UserDaoMySqlImpl implements UserDao {
    @Override
    public void getUser() {
        System.out.println("MySql獲取使用者資料");
    }
}

• 緊接著我們要去使用MySql的話 , 我們就需要去service實現類裡面修改對應的實現

public class UserServiceImpl implements UserService {
    private UserDao userDao = new UserDaoMySqlImpl();
 
    @Override
    public void getUser() {
        userDao.getUser();
    }
}
 

在假設, 我們再增加一個Userdao的實現類 .

public class UserDaoOracleImpl implements UserDao {
    @Override
    public void getUser() {
        System.out.println("Oracle獲取使用者資料");
    }
}

那麼我們要使用Oracle , 又需要去service實現類裡面修改對應的實現 . 假設我們的這種需求非常大 , 這種方式就根本不適用了, 甚至反人類對吧 , 每次變動 , 都需要修改大量程式碼 . 這種設計的耦合性太高了, 牽一髮而動全身 .

那我們如何去解決呢 ?

我們可以在需要用到他的地方 , 不去實現它 , 而是留出一個介面 , 利用set , 我們去程式碼裡修改下 .

public class UserServiceImpl implements UserService {
   private UserDao userDao;
// 利用set實現
   public void setUserDao(UserDao userDao) {
       this.userDao = userDao;
  }
 
   @Override
   public void getUser() {
       userDao.getUser();
  }
}

之前，程式主動建立物件，控制權在程式設計師手上。

使用了set注入後，程式不再具有主動性，而是變成了被動的接受物件

這種思想，從本質上解決了問題，我們程式設計師再也不用取關物件的建立了。系統的耦合性大大降低，專注業務上。這是IOC 的原型。