作者：鹿丸不会多项式 出处：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的概念，然后又列出并对比了三种注入方式的区别。