解耦应用与依赖注入框架

由于SOA、TDD等众多因素的影响，依赖注入已成为近年来广为接受的软件开发方法，随之而来的则是依赖注入框架的大量应用（尤其是最近Java EE 6所包含的依赖注入）。Bob Martin则通过实例演示了一种解耦应用代码与依赖注入框架的方法。

在Dependency Injection Inversion这篇文章中，Bob大叔总结到：

...我可不想让依赖注入框架的代码散布在我的应用当中。相反，我想解耦框架与我自己编写的代码。

为了阐述这个问题，Martin给出了一个示例，该示例围绕着BillingService类的创建展开，该类的构造方法定义了如下依赖：

public class BillingService {
	...
	BillingService(CreditCardProcessor processor, TransactionLog transactionLog) {
		this.processor = processor;
		this.transactionLog = transactionLog;
	}
	...
}

首先，Martin使用Guice（Google推出的依赖注入框架）创建BillingService类的实例：

public static void main(String[] args) {
	Injector injector = Guice.createInjector(new BillingModule());
	BillingService billingService = injector.getInstance(BillingService.class);
	billingService.processCharge(2034, "Bob");
}

在解释完该段代码的一些细节后，Martin给出这样一个事实：我们不得不显式地让Guice通过injector来创建BillingService的实例。这么做的结果就是：使用BillingService的代码不再依赖BillingService的依赖了（这很好），但却依赖Guice了。

是不是有利就有弊呢？Martin的回答是肯定的：

依赖注入不过是依赖倒置（Dependency Inversion）的一个特殊情况而已。我认为依赖倒置非常重要，因此打算转换对Guice的依赖。我可不想让那么多的Guice依赖搞乱了我的代码。

之后，他向我们展示了如何通过工厂对象来控制并降低应用对DI框架的依赖：

public static void main(String[] args) {
	Injector injector = Guice.createInjector(new BillingModule());
	BillingService.factory = new BillingServiceFactory(injector);
}
...
// Deep in the bowels of my system.
BillingService billingService = BillingService.factory.make();
billingService.processCharge(2034, "Bob");

为什么这种方式比较好呢，Martin说到：

我喜欢这么做，因为现在所有的Guice代码都放在了同一个地方，而非散布在应用的各个角落，这是通过工厂实现的。不仅如此，如果将Guice替换成其他DI框架，我会明确知道需要修改哪些类以及如何修改他们。通过这种方式达到了应用与Guice解耦的目的。

要澄清的一点是：在所有的示例中，BillingService本身都坚持着依赖注入原则，而BillingService到底使用的是依赖（CreditCardProcessor及TransactionLog）的何种实现其本身是不得而知的。为了说明这一点，他在文章的最后通过JUnit对BillingService进行了测试，在测试中仅仅使用了简单的TransactionLog和CreditCardProcessor实例对其进行注入，最后无论应用使用何种依赖注入手段，测试结果都是正确的。

Gary Bernhardt就这个测试也给出了一篇文章，提到在Java这种静态类型语言中这么做需要慎之又慎，但对于Python之类的动态语言就无所谓了。

你是否使用依赖注入呢？是否使用DI框架呢？不管答案如何，以上这种做法是否与你产生共鸣了呢？

查看英文原文：Decoupling Your Application From Your Dependency Injection Framework

有InfoQ读者对Bob大叔的这种做法提出了不同的观点：

来自InfoQ英文站的读者monser corp说到：

我想知道Bob大叔在过去几年编了多少代码？

恩，这是一种典型的”顾问式“做法：了解一项新技术，拿起来玩弄一下，然后发表在博客上来满足自己的虚荣心。在我做过的很多项目（使用了Spring）中，只有一个类会依赖于Spring：获取Context并启动应用。99.99%的代码都不知道Spring或Guice是啥（如果不是使用了Spring的某些库的话，IoC容器与Log4J根本就没啥区别）。如果真的想将代码与容器解耦，你需要重新考虑设计与实现，而非使用另一个工厂。

作为读者的您有何高见呢？这里，译者推荐您先去阅读Bob大叔的原文，然后将您的高见发表在这里。