Guice 是谷歌推出的一款轻量级的依赖注入（DI）框架，它帮我们解决Java项目中的依赖注入问题，提高了可维护性，可测试性和灵活性。Guice让DI变得简单易用，熟悉Spring的同学应该了解到依赖注入是一个很有用的设计模式，但如果你的项目中只想使用DI，但又不需要用到Spring这样一套比较重的框架，那么此时Guice会是一个很好的选择。
作为开始，首先我们回顾一下什么是依赖注入。依赖注入是一种设计模式，它的核心思想把行为与依赖分离开。具体什么意思呢，我们举几个例子就明白了。假如我们要设计一个定pizza的系统，首先我们有个billing service接口，它会通过当前的pizza订单和提供的信用卡信息来收费，并且返回相应的收据，成功和失败都有相对应的收据。
public interface BillingService {
/**
* Attempts to charge the order to the credit card.
* Both successful and failed transactions will be recorded.
* @return a receipt of the transaction.
*/
Receipt chargeOrder(PizzaOrder order, CreditCard creditCard);
}
这个时候，如果回到Java开发的石器时代，不使用任何依赖注入手段，我们只是把所有依赖都new出来的话，是什么样呢？
public class RealBillingService implements BillingService {
public Receipt chargeOrder(PizzaOrder order, CreditCard creditCard) {
CreditCardProcessor processor = new PaypalCreditCardProcessor();
try {
ChargeResult result = processor.charge(creditCard, order.getAmount());
return result.isSuccessful() ?
Receipt.forSuccessfulCharge(order.getAmount())
: Receipt.forDeclinedCharge(result.getDeclineMessage());
} catch (Exception e) {
return Receipt.forSystemFailure(e.getMessage());
}
}
}
我们有一个真实收费服务的类实现了这个接口，并且把相关的依赖都new出来了。显然，在现在真实的开发环境里大家都不会这么写，对吧，这会有什么问题呢？首先，最明显的问题就是测试，这段代码在测试的时候居然会调用真实的credit card processor的收费逻辑！并且在刷卡消费被decline掉的时候也很难测试。这段代码里billing service和credit card processor的耦合太严重了，我们需要去优化。
首先想到的可能是工厂模式，我们可以提供一个credit card process的工厂，来把创建具体credit card processor的逻辑放在工厂里面。这样的话是可行的，并且测试的时候，我们只需要在单元测试的 setup() 方法中通过工厂提供的 setInstance() 接口把我们fake的credit card processor传进去就好了。但是我们都知道，工厂模式需要些一些模板代码，并且最大的问题是代码的依赖关系都藏在code里了，如果我们加了新的依赖，按照上述办法我们还需要建立新的工厂来应对这些依赖，并且如果一旦我们忘记给新的依赖建立一个合适的工厂，那我们只有在运行时而不是编译时才能发现错误。
好了，终于到了依赖注入来显身手了。前面说过，依赖注入是为了把行为和依赖解耦开，在上面的例子里面，billiing service其实并不需要负责创建或者查找credit card processor，相反地，我们只需通过构造函数的参数传进来具体的实现即可。
public class RealBillingService implements BillingService {
private final CreditCardProcessor processor;
public RealBillingService(CreditCardProcessor processor) {
this.processor = processor;
}
public Receipt chargeOrder(PizzaOrder order, CreditCard creditCard) {
try {
ChargeResult result = processor.charge(creditCard, order.getAmount());
return result.wasSuccessful()
? Receipt.forSuccessfulCharge(order.getAmount())
: Receipt.forDeclinedCharge(result.getDeclineMessage());
} catch (UnreachableException e) {
return Receipt.forSystemFailure(e.getMessage());
}
}
}
public static void main(String[] args) {
CreditCardProcessor processor = new PaypalCreditCardProcessor();
BillingService billingService
= new RealBillingService(processor);
//...
}
例子很简单，但这其实就是依赖注入的核心思想，程序并不需要关心你的依赖是如何创建的，我只是声明我需要这个依赖，而有其他某个地方帮我负责生成这个依赖，也就是大家常听说过的：控制反转。
此时，当我写测试的时候，可以直接将fake的credit card processor传进real billing service的构造函数。并且，当我们添加或者删除某个依赖的时候，不像工厂模式那样，编译器就会告诉我们哪些依赖还需要添加或者删除。
好的，依赖注入的背景基本上已经讲完了，下面我们来看一下使用Guice，是如何做到的，直接上代码：
public class RealBillingService implements BillingService {
private final CreditCardProcessor processor;
@Inject
public RealBillingService(CreditCardProcessor processor) {
this.processor = processor;
}
public Receipt chargeOrder(PizzaOrder order, CreditCard creditCard) {
try {
ChargeResult result = processor.charge(creditCard, order.getAmount());
return result.wasSuccessful()
? Receipt.forSuccessfulCharge(order.getAmount())
: Receipt.forDeclinedCharge(result.getDeclineMessage());
} catch (UnreachableException e) {
return Receipt.forSystemFailure(e.getMessage());
}
}
}
熟悉spring的同学应该很好理解Guice的注解，通过给构造函数上加上@Inject注解，告诉我们credit card processor这个依赖是由Guice负责帮我们绑定进来的。好了，那么我们还需要什么呢？还需要知道究竟Guice是怎么帮我们绑定的，来告知我们怎么样把依赖的接口和实现类map起来，这个配置是通过一个继承了Guice的AbstractModule的Java类来实现的，只需要override它的config()方法即可:
public class BillingModule extends AbstractModule {
@Override
protected void configure() {
bind(CreditCardProcessor.class).to(PaypalCreditCardProcessor.class);
bind(BillingService.class).to(RealBillingService.class);
}
}
然后当我们调用的时候，就简化成了：
public static void main(String[] args) {
Injector injector = Guice.createInjector(new BillingModule());
BillingService billingService = injector.getInstance(BillingService.class);
//...
}
Injector可以用来获取任何被绑定类的一个实例。
关于更加深入的Guice细节，请移步 Guice教程2
网友评论