【曹工杂谈】Maven IOC容器的下半场：Google Guice

Maven容器的下半场：Guice

前言

在前面的文章里，Maven底层容器Plexus Container的前世今生，一代芳华终落幕，我们提到，在Plexus Container退任后，取而代之的底层容器是Guice。

Guice的应用也还比较广泛，以下轮子中（仅部分）都有它活跃的身影：

• google内部
• scalatest
• TestNG
• Caffeine Cache
• Spring Security Config
• elastic search
• jenkins

这很多轮子，都是直接用的Guice，那是因为没什么历史包袱；但Maven不一样，maven之前用自己的IOC轮子，有自己独特的定义组件的方式（比如Spring通过@Component注解来定义）；但是Guice作为一个独立的IOC框架，那肯定是不认识Maven中的组件的。

因此，这中间肯定需要兼容啊，Maven的组件，还是用的Plexus IOC容器那套方式去定义，但是他们开发了一个中间层，把那些组件解析后，存放到了Guice容器中。

这里说，把组件解析后，存放到了Guice容器中，这个也不是特别准确，更准确的说法是，放到了基于Guice进行了一层封装的一个容器中，这个容器叫做：sisu，由eclipse在维护这个开源项目（https://www.eclipse.org/sisu/）。

可能你就疑惑了，就一个破IOC，搞得多有技术含量一样，还一层套一层。。这个我们就先不管了，这期我先讲Guice，然后大家就懂了，为啥Sisu要要封装一层了。总结一下，依赖路径是：

最底层的是google Guice --》 sisu（eclipse）--》 sisu-plexus兼容层--》plexus --》maven。

好了，开始正文。

Guice是什么

根据wiki的描述，Guice就是依赖注入框架，由google开源。主要特点就是：支持以java注解的方式配置组件及依赖。最早的版本应该是在2007年，我还找到一篇当年的报道 https://developers.googleblog.com/2007/03/，

当时还是2007年，而2004年的时候，支持注解的JDK1.5才放出来，与此同时，Spring早期版本主要也还是以xml配置为主，Guice在那时就支持全注解配置，以当时的眼光来看，很前沿了。

接下来，我们就来仔细了解下Guice的用法。

核心理念

在开始讲之前，我说下我对IOC框架的理解先。很多时候，可以简单地说，IOC容器是一个map，一个放东西的地方，就像一个中药房，每个格子里会放一种药材，而每个格子上，有一个标签，来说明里面放的是什么药材。

既然是放东西的地方，核心就是两个部分，怎么放，放的时候，可能就要考虑到后续怎么找的问题。比如，如果你打算只支持根据物品的类型来找，那你要考虑到：如果这个类型的物品有多个，要怎么办？怎么区分这多个物品？

如果你打算解决这个问题，那你可能就会想：那我放的时候，再给这些物品取个名字吧，免得多个相同类型的物品，分不清。

甚至呢，你可能会考虑，物品的权限隔离，比如，物品上再加个存放人的字段，以后取得时候，就只能：自己取自己的，不能取别人的。

反正，最终还是看需求，一般来说，像我们spring这种，按类型就差不多了，一个类型多个实现的时候，再根据名字区分一下就ok。

而Guice呢，我这边会重点讲解：怎么存。至于取，可能还分成两种，依赖注入和直接从容器中取。但是依赖注入的底层实现，也是：发现我依赖的某个东西没有，就去容器里取。

所以，取东西，我们只需要关注：直接从容器中怎么获取就行；我这边就不会特别关注依赖注入的问题。

Guice中，存东西的多种方式

概览

存东西，在Guice的文档里，名词叫做Binding，中文就是绑定吧。

https://github.com/google/guice/wiki/Bindings

绑定是什么意思，就是我最终可能需要从容器中获取ClassA类型的对象。既然要取，那还得先存，存的时候，我就要建立绑定：ClassA --》该Class类型对象的获取方式。

其实还是很简单的。下边就跟着我的代码例子，我们来看看。

以下全部的代码，都在：

https://gitee.com/ckl111/maven-3.8.1-source-learn/tree/master/my-test-modules/official-guice-demo

1. linkedbinding-绑定接口到实现类

先来一个接口和实现：

public interface HelloInterface {
    void hello();
}
public class HelloInterfaceImpl implements HelloInterface {
    @Override
    public void hello() {
        System.out.println("hello world");
    }
}

再来看看，怎么放到容器，和简单的从容器中取出来的方法：

大家看我代码截图，放东西的时候，就是要指定这个接口，对应的实现类。

取东西的时候，再去根据接口取就行了。

2.BindingAnnotations 一个类型有多个实现类的时候的绑定方式

接口和多个实现类：

interface HelloInterface {
    void hello();
}
class HelloInterfaceImpl implements HelloInterface {

    @Override
    public void hello() {
        System.out.println("hello world");
    }
}

class HelloInterfaceImpl2 implements HelloInterface {

    @Override
    public void hello() {
        System.out.println("hello world");
    }
}

如果我们还是按前面的办法去取，框架就晕圈了，多个实现类，我给你哪一个呢？麻烦再明确一下吧，ok吗

Guice有个注解，叫Named，可以加在各种地方，注解本身，支持设置名称。

这里意思就是说，你接口不是多个实现吗，那我们这样：接口+注解，才算是唯一的key，这样ok了吧。

因此，现在就变成了这样：接口+注解1 --》 实现类1；接口 + 注解2 --》 实现类2.

那我怎么取呢？简单啊，怎么存，怎么取，存的时候，用的接口+注解，取的时候，也需要这样。

既然，可以用官方的Named注解，那其实自己的注解也一样可以用。

3. InstanceBindings 接口直接绑定一个单例对象

如果同一个类型，要绑定到多个实例的情况，同前面的处理方式一样。

4. 绑定到工厂方法：授人以鱼不如授人以渔

前面都是些直来直去的办法，这次不一样，我只告诉你，这个东西的获得方法。

5. 不用接口了，直接绑定一个实现类

前面都是根据一个接口类，去取接口对应的实现之类的。这次不一样，直接就是一个实现类了。

public class UtilService {
}

像上面这个情况，那肯定是直接调用这个类的构造函数了。

6. 接口绑定到一个构造函数：ToConstructorBindings

哎，我是越来越无语了，Guice的骚操作真是多啊。

7. 内置的不用绑就能用的

主要有：Logger、Injector本身（就是相当于可以帮你注入容器自身）

8. 能不能不绑定直接用

用惯了spring的我们，现在已经是不需要这么绑来绑去了。我们看看Guice的支持怎么样

不绑定的话，可以这样：

@ImplementedBy(TestInterfaceImpl.class)
interface TestInterface {
}

这就相当于，你要自己指定一下，你的实现类是谁，或者你的provider是谁。但是官方不建议用这种隐式绑定，不知道为啥，还出了个选项，专门禁用隐式绑定。

9. 一个接口多个实现类，一次性全获取回来

这个场景，就是一次性把多实现类一把取回来，放到一个集合里给你。

这个场景我没写代码，大家自己看一下文档，也简单。

10. 注入的方式

前面说了很多怎么手动从容器里面取，当然了，要自动注入的话，也是支持：构造器注入、field注入等等方式。

如以下为构造器注入：

其他支持的特性

其他的，比如循环依赖、aop也是大体支持的，只是这个容器在安卓端用，会有问题，因为aop好像不太支持，所以给安卓端还专供了一个去掉aop的版本。

循环依赖之类的，具体实现还没怎么看过。

另外，guice默认生成的是多例（类比spring的prototype，而不是singleton），但是本身也是支持singleton的，我前面的代码例子有。

最大槽点

可以看出，Guice是很轻量，轻量的意思是，功能没Spring那么全，所以，我们还需要去显式地：配置每个接口，要怎么获取它的对象（方法也是五花八门，哈哈哈，如前面展示的）。

当然，配置ok后，我们获取某对象的时候，它会帮我们去完成自动注入的东西。

但是，它也不支持类路径扫描啊，比如给个包名，自动去扫描这个包下面的组件，反正官方不支持，说是有第三方插件，还没试过。

总结

在各种轮子里，用来管理自己的代码间的相互依赖，用Guice确实足够了，用在业务代码，就还是有点累。

因为，主要是：各种依赖要自己配，只是集中在一个地方配置而已，没有像spring那样，约定通过接口找对象时，默认就是找实现类，然后反射生成对象。

这一点来说，确实是：约定优于配置，就像Maven为啥打败了ant，也是这个道理。

另外的问题就是，不支持spring的那种component-scan。

基于这两个问题呢，方法肯定是有的，所以，Maven也足够聪明，没有直接基于Guice，而是选择了基于Guice封装后的Sisu，而Sisu就可以解决我们说的问题，支持类路径扫描之类的。

我们看看sisu怎么介绍自己：

就是比Guice多了些看起来还很不错的、Spring早已有了的特性吧。回头我们肯定要再介绍sisu的。

再见，以上。