依赖倒置原则(DIP),依赖注入(DI),控制反转(IoC)

原文链接:http://www.importnew.com/1019.html

Question:
对于依赖倒置原则（Dependency Inversion Principle，DIP），依赖注入（Dependency Injection，DI）和控制反转（Inversion of Control，IoC）容器，你是怎么理解的？

Answer:
依赖倒置原则（Dependency Inversion Principle, DIP）。这个设计准则某种程度上和依赖注入模式有些关联。DIP的出发点是：在应用开发中，高层模块不应当直接依赖低层模块。DIP并不意味着依赖注入。这个准则并没有讲到高层模块如何知道调用哪个低层模块。不过这一点通过实现工厂模式接口可以间接获知，或者通过类似Spring框架、Pico容器、Guice或者Apache HiveMind之类的loC容器实现依赖注入从而得知高层模块调用的具体哪个低层模块。



DIP意味着：

高层模块不应当依赖低层模块，它们都应当依赖抽象。
抽象不应该依赖具体实现。具体实现应该依赖抽象。
应用这个准则后，高层模块并不直接同低层模块交互，而是通过一个抽象层来跟低层模块进行交互。这使得需求变更后增加的成本更加灵 活可控。这里有些实现DIP的示例代码片段。

首先定义抽象层：
package principle_dip2;
public interface AnimalHandler {
    public abstract void handle( );
}
package principle_dip2;
public interface AnimalHelper {
    public abstract void help( );
}
接着是依赖于抽象类而非具体实现的高层代码。

package principle_dip2;
public class CircusService {
    AnimalHandler handler;
    public void setHandler(AnimalHandler handler) {
        this.handler = handler;
    }
    public void showStarts( ) {
        //code omitted for brevity
        handler.handle( );
    }
}
package principle_dip2;
public class TigerHandler implements AnimalHandler{
    AnimalHelper helper;
    public void setHelper(AnimalHelper helper) {
        this.helper = helper;
    }
    public void handle( ){
        //...
        helper.help( );
        //...
    }
}
package principle_dip2;
public class TigerHelper implements AnimalHelper{
    public void help( ){
        //......
    }
}

依赖注入模式（Dependency Injection）：在运行时将类的依赖注入到代码中。通过将依赖定义为接口，并将实现这个接口的实体类注入到主类的构造器中来实现这个模式。这允许程序员在不同的实现之间转换而不用去修改主类。依赖注入模式可以通过单一责任原则（Single Responsibility Principle）SRP来使得代码高内聚（high cohesion），因为所依赖的通常都是完成独立的功能的对象，例如，（通过DAO进行）数据存取或（通过Service和Delegate类实现）业务服务。

控制反转容器（Inversion of Control Container，IoC），是一个支持依赖注入的容器。这种方式下，可以采用一个中心容器，例如Spring框架，Guice或者HiveMind，来定义哪个依赖应该使用哪个实体类。Ioc的松耦合性可以带来更多的灵活性，并且在程序运行时更容易去切换到正确的依赖对象上。控制反转模式的基本概念是，不去实际生成对象，而是去定义如何生成对象。不用直接在代码中将模块和服务硬编码在一起，而是在配置文件中描述哪个模块需要哪个服务。容器（例如Spring框架这个IoC容器）会负责将这两者绑定起来。应用IoC的时候，某对象所需的依赖会在创建的时候通过外部实体传入，这些外部实体用来协调系统中的不同对象。也就是说，依赖是被注入到对象中去的。因此，IoC就是关于一个对象如何获得其协作对象的引用的一种责任反转机制。

DI和IoC的真正强大之处在于，在运行时而非编译时绑定类间关系。例如，在Seam框架中，你可以对一个接口进行两种实现：真正的实现和模拟(mock)的实现，而在运行时根据某个属性、另一个文件存在与否或者某个优先值去决定真正调用哪一个实现。这尤其当你希望程序在不同场景下表现不同的行为时，这是非常好用的。DI和IoC的另外一个好处是，使得代码更容易进行单元测试。当然也有其他一些好处，例如，不用使用工厂或者单例模式就可以实现松耦合，其实现方法一致因此适合缺乏经验的程序员，等等。当然，享受这些好处是要付出代价的，例如系统复杂性会随之增加，另外在使用时也需要更加小心，不能因为这个技术受欢迎就滥用，而是在能够真正体现其优势的地方才去使用。

注意：上下文依赖注入（Contexts and Dependency Injection）是用来描述标准依赖注入的一个尝试。CDI是Java EE 6 stack的一部分，也就是说任何一个运行在Java EE 6兼容容器之上的应用都可以轻松使用CDI。Weld就是CDI的一个可参考的实现。