作者：鹿丸不會多項式 出處：http://www.cnblogs.com/hechao123 轉載請先與我聯系。

在看ico概念之前，先想一下我們平常需要依賴某個類時會怎麽做？

無非是在要用到的地方寫如下代碼：

Person person = new Person();
//然後就可以用person對象來獲取Person類提供的服務了
person.say("hellow Ioc!");

先不說這樣做有什麽不好，想一下我們的目的只是想調用person的說話服務而已，每次調用前都需要自己創建個person對象這樣是否真的有必要？答案當然是no。

在上面的例子中，被註入對象直接依賴於被依賴對象(先理清這兩個名詞)，但實際上被註入對象並不需要關心被依賴對象具體是誰？什麽時候被創建？它只需要在要用到被依賴對象的時候，被依賴對象能準備好為它服務。要實現這種模式就需要第三個對象介入，被依賴對象不需要關心的都交給它去做，這就是ioc模式。

這張圖很好地說明了ioc的工作模式，那麽問題又來了，Ioc Service Provider(ioc服務提供者)怎麽知道被註入對象需要哪些被依賴對象呢？Ioc Service Provider要服務很多被註入對象，如果讓它一個個去問：您需要什麽對象呢？這樣會把它搞糊塗或者忙不過來，所以需要被註入對象去通知它。那麽，怎麽通知呢？

ioc模式裏用到3種方式：

1.構造方法註入

public Team(Person person){
    this.person = person;
}

Ioc Service Provider會檢查被註入對象的構造方法，取得它所需要的依賴對象列表，進而為其註入相應的對象。同一個對象是不可能被註入兩次的，因此，被註入對象的構造乃至整個生命周期應該是由Ioc Service Provider來管理的。構造方法註入方式比較直觀，對象完成構造後，它所依賴的對象也已經註入完成，隨時可以使用。

2.setter方法註入

private Person person;
public Person getPerson(){
    return person;
}
public void setPerson(Person person){
    this.person = person;
}

這樣Ioc Service Provider就可以在適當的時候通過調用setPerson方法為當前對象註入所依賴的person對象了。跟構造方法的不同在於這個註入過程是發生在被註入對象構造完成之後一個不確定的時間裏，不過我們並不關心在什麽時候註入。

3.接口註入

接口註入比較麻煩，被註入對象如果想要Ioc Service Provider為其註入依賴對象，就必須實現某個接口，這個接口提供一個方法用來為其註入對象，現在已經沒有ioc框架在用了，這裏就不再詳細說明。

比較一下三種註入方式：

後邊一節Ioc的附加值看完之後理解了但是覺得作者舉得例子並不好，之前在網上看到一個例子感覺說到了精髓，有興趣的可以看看：http://www.cnblogs.com/cyq1162/archive/2013/06/06/3120231.html

總結：

本章主要介紹了Ioc模式解決了什麽問題，以便更好第理解ioc的概念，然後又列出並對比了三種註入方式的區別。

spring揭秘 第二章 ioc的基本概念