关于IoC与DI（二）

　　IoC的概念早在1988年就出现在了面向对象编程相关的杂志上了，而它的思想来源——好莱坞法的出现则要追溯到1983年。和这些相比，总是和IoC一起被提及的DI却出现的晚的多。
　　随着开发人员对IoC的理解与运用，逐渐衍生出了不同种类的模式与框架。一类就是服务定位器（Service Locator），JNDI（Java Naming and Directory Interface）就是这类框架的代表。而另一类被用来帮助开发者将不同类型的组件装配成一个内聚的系统。他们都遵循同一个模式，也正是这个模式决定了这些容器进行组建装配的方式。但是当时并没有一个很好的形容这种模式的定义。所以它往往被叫做IoC容器。当然，这么叫是不太恰当的，因为这一类容器和服务定位器一样，只是关注于IoC的一个方面。2004年，在Java社区中掀起了一场对其命名的争论，并最终使用由Fowler等人提出的一个更加精确的名称——依赖注入（Dependency Injection）。
　　从字面上理解，依赖注入就是将服务注入到使用它的地方。注入过程是由容器根据一定规 则（通常为外部配置文件）完成的。而他和服务定位器的主要区别也就在注入上边，前者是被动的后者是主动的。下边就从我们的日常生活中抽象出一个小例子来更形象的说明一下。
　　我们要描述的场景是吃饭，有三个对象，人、食物和餐具。很显然，人需要使用餐具提供的服务才能顺利地吃到饭。首先定义他们的接口：

public interface Food {
    // 取得食物的名称
    public String getName();
}

public interface Tableware {
    // 被使用，成功就返回true
    public boolean act(Food food);
}

public abstract class People {
    // 使用的餐具
    protected Tableware tableware;

    // 吃饭，吃到了就返回true
    public boolean eat(Food food) {
        return this. tableware.act(food);
    }
}

　　接口定义好了，具体的对象间就不会有耦合关系了。接下来是个两个场景，中午小王用筷子吃面条和早上小王用勺子喝粥。于是我们又有了小王、筷子、勺子、面条和粥这几个对象：

public class Noodle implements Food {
    public String getName() {
        return “noodle”;
    }
}

public class Conjee implements Food {
    public String getName() {
        return “conjee”;
    }
}

public class Chopsticks implements Tableware {
    public boolean act(Food food) {
        return “noodle”.equals(food.getName());
    }
}

public class Scoop implements Tableware {
    public boolean act(Food food) {
        return “conjee”.equals(food.getName());
    }
}

　　现在问题出现了，小王应该如何得到他需要的餐具呢？

方式１：

public class WangWithChopsticks extends People {
    public WangWithChopsticks () {
        this.tableware = new Chopsticks();
    }
}

　这种方式不符合IoC思想，这个小王已经被限定成了拿着筷子的小王，他喝不到粥了。

方式2：

public class Wang extends People {
    public Wang () {
        this.tableware = (Tableware) ServiceLocator.getService(“Current Tableware”);
    }
}

　　这就是使用服务定位器的样子。小王主动的去食堂大妈那里要一个餐具，当然什么餐具是大妈说了算。这样做的好处是你可以使用getService(“Chopsticks”)这样更直观的方法来取餐具。在调试复杂系统的过程中，这点是至关重要的。但它也有弱点，那就是代码中留下了容器的影子，也就是说组件和组件所在的容器紧密地耦合在一起了，如果需要更换容器将非常麻烦。用这个例子来说就是，小王只能朝食堂大妈要餐具，如果要换成大叔，那就只能重新做一个小王了。

方式3：

public class Wang extends People {
    public Wang (Tableware tableware) {
        this.tableware = tableware;
    }
}

　　这就是符合DI要求的小王了。这种写法很直接，因为没有外部条件影响下的小王本来就应该这个样子。但是这个普通的小王存在于一个神奇的空间（DI容器）中，当他想用餐具的时候，就会发现一个餐具刚好摆在了手边，不用去关心是谁放在那里的。DI容器的原理其实并不神奇，就是由容器管理对象的生成，在生成的过程中将需要的服务注入到对象中。但问题是注入的是什么餐具，仅从小王的代码中是绝对猜不到的，这在调试的时候就有些不便了。
　　对于服务定位器与依赖注入两种实现方式的取舍，Fowler有个非常精辟的见解：问题在于代码的作者是否希望自己编写的组件能够脱离自己的控制，被使用在另一个应用程序中。Fowler推荐尽量使用服务定位器，因为系统容器变更的情况较少见，但是调试却是麻烦的事情。