IoC和依赖注入

Question

以下代码有什么问题？

public class DeDoper {
    public boolean wackapediaOkToday() {
        DnsResolver resolver =  ResolverFactory.getInstance().makeResolver();
        return resolver.getIpAddressFor("wackapedia.org").equals("123.456.78.9");
    }
}

为什么这个版本更受欢迎？

public class DeDoper {
    @InjectService
    private DnsResolver resolver;

    public boolean wackapediaOkToday() {
        return resolver.getIpAddressFor("wackapedia.org").equals("123.456.78.9");
    }
}

我可以轻松地模拟ResolverFactory.makeResolver（），这与设置解析器是最新的例子相同。

这就是ProQuest.biz在这篇文章中所说的：

WackapediaOkToday的这个[第一个]版本，非常宽松地说，“注入”DnsResolver（虽然它不像是一个镜头，更像是要求服务员检查）。 但它确实解决了测试问题，以及“乌龟一直向下”的问题。

链接到工厂但是在[第一版]方法中，我们实际上是“链接”到工厂类。 （更糟糕的是，如果我们的工厂创建的对象依次具有依赖关系，我们可能不得不在我们的工厂中引入新的工厂。）我们还没有完全“颠倒”我们的控制，我们仍然从内部调用（控制）工厂我们的课程。

我们需要的是一种完全摆脱我们课程控制的方法，让他们告诉他们得到的东西（因为他们的依赖）。

Answer 1

假设你有一个可以有多个实现的服务，比如“FileLocator”。 它有一个FilesystemFileLocator，它将文件根目录的路径和S3FileLocator作为参数，将S3凭据作为参数。 前者需要您编写服务定位器以确定您想要的版本然后将其返回。 反过来，该代码必须获取您的数据，构建适当类型的文件定位器等。您正在做IOC容器应该为您做的事情。 最重要的是，您已经为该特定创建方法注入了依赖项。

在第二个版本中，您已经（通过注释或XML）定义了所需的文件定位器类型。 IOC容器为您实例化并管理它。 你需要维护的代码更少。 如果要引入第三种类型的FileLocator，它的工作量也会减少。 或者你可能重构你的代码，所以文件定位器是单例，或者如果它们是单例，它们现在是新的定位器的工厂，或者你可能想要池定位器实例。 在所有这些情况下，如果您使用IOC容器，将会减少破损。