1. 程式人生 > 其它 >spring學習:概述及IOC理論推導

spring學習:概述及IOC理論推導

新建一個空白的maven專案

2 .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、測試一下(這裡每次更換不同介面都需要在service層更改new的介面)
@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方法就可以在呼叫的時候由使用者選擇呼叫的介面)

@Test
public void test(){
   UserServiceImpl service = new UserServiceImpl();
   service.setUserDao( new UserDaoMySqlImpl() );
   service.getUser();
   //那我們現在又想用Oracle去實現呢
   service.setUserDao( new UserDaoOracleImpl() );
   service.getUser();
}

大家發現了區別沒有 ? 可能很多人說沒啥區別 . 但是同學們 , 他們已經發生了根本性的變化 , 很多地方都不一樣了 . 仔細去思考一下 ,以前所有東西都是由程式去進行控制建立,而現在是由我們自行控制建立物件 , 把主動權交給了呼叫者. 程式不用去管怎麼建立,怎麼實現了 . 它只負責提供一個介面 .

這種思想 , 從本質上解決了問題 , 我們程式設計師不再去管理物件的建立了 , 更多的去關注業務的實現 . 耦合性大大降低 . 這也就是IOC的原型 !

2.1.2IOC本質

控制反轉IoC(Inversion of Control),是一種設計思想,DI(依賴注入)是實現IoC的一種方法,也有人認為DI只是IoC的另一種說法。沒有IoC的程式中 , 我們使用面向物件程式設計 , 物件的建立與物件間的依賴關係完全硬編碼在程式中,物件的建立由程式自己控制,控制反轉後將物件的建立轉移給第三方,個人認為所謂控制反轉就是:獲得依賴物件的方式反轉了。

IoC是Spring框架的核心內容,使用多種方式完美的實現了IoC,可以使用XML配置,也可以使用註解,新版本的Spring也可以零配置實現IoC。

Spring容器在初始化時先讀取配置檔案,根據配置檔案或元資料建立與組織物件存入容器中,程式使用時再從Ioc容器中取出需要的物件。

採用XML方式配置Bean的時候,Bean的定義資訊是和實現分離的,而採用註解的方式可以把兩者合為一體,Bean的定義資訊直接以註解的形式定義在實現類中,從而達到了零配置的目的。

控制反轉是一種通過描述(XML或註解)並通過第三方去生產或獲取特定物件的方式。在Spring中實現控制反轉的是IoC容器,其實現方法是依賴注入(Dependency Injection,DI)。