IOC控制反转

接口可以提供不同的子类实现，增加代码稳定和健壮性等等，但是接口一定是需要实现的，也就是如下语句迟早要执行：

AInterface a = new AInterfaceImp(); 这样一来，耦合关系就产生了，如：

Class A {
AInterface a;　
void aMethod() { a = new AInterfaceImp(); }
}

ClassA与AInterfaceImp就是依赖关系，如果想使用AInterface的另外一个实现就需要更改代码了。当然我们可以建立一个Factory来根据条件生成想要的AInterface的具体实现，即：

InterfaceImplFactory {
    AInterface create(Object condition) { 　　
      1、 if(condition == condA) { return new AInterfaceImpA(); } 　　
      2 、else if(condition == condB) {return new AInterfaceImpB(); }
      3 、else { return new AInterfaceImp(); }
    }
}

表面上是在一定程度上缓解了以上问题，但实质上这种代码耦合并没有改变。

IoC模式把耦合从代码中移出，放到 XML 文件中，通过一个容器在需要的时候把依赖关系形成，即把需要的接口实现注入到需要它的类中，这可能就是“依赖注入”说法的来源了。

　IOC模式，可由 IOC容器来管理对象的生命周期、依赖关系等，从而使得应用程序的配置和依赖性规范与实际的应用程序代码分开。其中一个特点就是通过文本的配件文件进行应用程序组件间相互关系的配置，而不用重新修改并编译具体的代码。

可以把IoC模式看做是工厂模式的升华：

1、可以把IoC看作是一个大工厂，在XML文件中定义要生成的对象,利用Java 的“反射”编程，根据XML中给出的类名生成相应的对象,提高灵活性和可维护性

2、反射就是根据给出的类名（字符串）来生成对象。让对象在生成时,才决定要生成哪一种对象。反射方式生成对象比通常对象生成方式速度慢一陪

猜你喜欢