什么是IOC，什么时候用IOC

Inverse of control 的简写简单的理解依赖注入就是让对象（包括属性）的创建，在运行时，通过某些配置去创建对象或者生成这个属性。为什么需要IOCIOC的目的是解耦。
因此首先理解什么是依赖
Interface bi;
Class b implements bi;
Class a 中，Class bi = new b();
a 和 bi是编译时耦合。
 Class a 中，Class bi = Class.forName("b").newInstance();
a 和 b 是运行时耦合，但是只是推迟了耦合的时机，和 1 没有本质区别。
3. Class a 中，Class bi = Class.forName(bname).newInstance();bname从外部配置文件中或者参数中获取。a 和 b 是潜在运行时耦合，你可以用类c替换b而不会影响a。IoC的效果和 3 一样。这样用的好处。首先这种对象的创建。一般是，也最好是置于某一个对象创建工厂中。主要为了方便以后更改。现在假设某一个类中。
有属性private A a;public A getA();public void setA();a的实现用依赖注入实现。那么如果以后这个类更改。可以自己随意在配置文件中更改而无需更改现有代码。这减少了类A和实现类A的类之间的耦合。上面属性A可以写成private A a＝new A();的。为什么一边说用配置文件去产生所在实现类A类。一边却这样去具体实现呢？主要是基于一个效率上的考虑。因为这样窗口不必去考虑A的实现类的多态多少。另外也没必要老是要让别人去注入依赖。毕竟我们写注入依赖是因为实现类可变更。但大部分情况下。我们都可以决定实现类。
另外。当业务模型中a必须依赖b的时候，最好的设计是1，这个时候代码最清楚、简洁，也最直接的表达出它们之间的耦合关系，如果用3反而使得a无法理解。当业务模型中a是依赖于bi的某一种实现的时候，最好的设计是3。注意，在设计过程中，解耦不是目的，让bi的实现可以不影响a而变化（前提是bi的实现确实存在潜在的变化可能）是目的。使用IOC也一样，不要把所有的依赖关系的分离，这样你的设计将让人无法理解，包括你自己。