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

最后编辑于
©著作权归作者所有,转载或内容合作请联系作者
  • 序言:七十年代末,一起剥皮案震惊了整个滨河市,随后出现的几起案子,更是在滨河造成了极大的恐慌,老刑警刘岩,带你破解...
    沈念sama阅读 218,607评论 6 507
  • 序言:滨河连续发生了三起死亡事件,死亡现场离奇诡异,居然都是意外死亡,警方通过查阅死者的电脑和手机,发现死者居然都...
    沈念sama阅读 93,239评论 3 395
  • 文/潘晓璐 我一进店门,熙熙楼的掌柜王于贵愁眉苦脸地迎上来,“玉大人,你说我怎么就摊上这事。” “怎么了?”我有些...
    开封第一讲书人阅读 164,960评论 0 355
  • 文/不坏的土叔 我叫张陵,是天一观的道长。 经常有香客问我,道长,这世上最难降的妖魔是什么? 我笑而不...
    开封第一讲书人阅读 58,750评论 1 294
  • 正文 为了忘掉前任,我火速办了婚礼,结果婚礼上,老公的妹妹穿的比我还像新娘。我一直安慰自己,他们只是感情好,可当我...
    茶点故事阅读 67,764评论 6 392
  • 文/花漫 我一把揭开白布。 她就那样静静地躺着,像睡着了一般。 火红的嫁衣衬着肌肤如雪。 梳的纹丝不乱的头发上,一...
    开封第一讲书人阅读 51,604评论 1 305
  • 那天,我揣着相机与录音,去河边找鬼。 笑死,一个胖子当着我的面吹牛,可吹牛的内容都是我干的。 我是一名探鬼主播,决...
    沈念sama阅读 40,347评论 3 418
  • 文/苍兰香墨 我猛地睁开眼,长吁一口气:“原来是场噩梦啊……” “哼!你这毒妇竟也来了?” 一声冷哼从身侧响起,我...
    开封第一讲书人阅读 39,253评论 0 276
  • 序言:老挝万荣一对情侣失踪,失踪者是张志新(化名)和其女友刘颖,没想到半个月后,有当地人在树林里发现了一具尸体,经...
    沈念sama阅读 45,702评论 1 315
  • 正文 独居荒郊野岭守林人离奇死亡,尸身上长有42处带血的脓包…… 初始之章·张勋 以下内容为张勋视角 年9月15日...
    茶点故事阅读 37,893评论 3 336
  • 正文 我和宋清朗相恋三年,在试婚纱的时候发现自己被绿了。 大学时的朋友给我发了我未婚夫和他白月光在一起吃饭的照片。...
    茶点故事阅读 40,015评论 1 348
  • 序言:一个原本活蹦乱跳的男人离奇死亡,死状恐怖,灵堂内的尸体忽然破棺而出,到底是诈尸还是另有隐情,我是刑警宁泽,带...
    沈念sama阅读 35,734评论 5 346
  • 正文 年R本政府宣布,位于F岛的核电站,受9级特大地震影响,放射性物质发生泄漏。R本人自食恶果不足惜,却给世界环境...
    茶点故事阅读 41,352评论 3 330
  • 文/蒙蒙 一、第九天 我趴在偏房一处隐蔽的房顶上张望。 院中可真热闹,春花似锦、人声如沸。这庄子的主人今日做“春日...
    开封第一讲书人阅读 31,934评论 0 22
  • 文/苍兰香墨 我抬头看了看天上的太阳。三九已至,却和暖如春,着一层夹袄步出监牢的瞬间,已是汗流浃背。 一阵脚步声响...
    开封第一讲书人阅读 33,052评论 1 270
  • 我被黑心中介骗来泰国打工, 没想到刚下飞机就差点儿被人妖公主榨干…… 1. 我叫王不留,地道东北人。 一个月前我还...
    沈念sama阅读 48,216评论 3 371
  • 正文 我出身青楼,却偏偏与公主长得像,于是被迫代替她去往敌国和亲。 传闻我的和亲对象是个残疾皇子,可洞房花烛夜当晚...
    茶点故事阅读 44,969评论 2 355