Guice 教程(1)
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