【曹工杂谈】Maven IOC容器的下半场:Google 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的。

再见,以上。

本文由博客一文多发平台 OpenWrite 发布!

你可能感兴趣的:(【曹工杂谈】Maven IOC容器的下半场:Google Guice)