前言
在前面的文章里,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...,
当时还是2007年,而2004年的时候,支持注解的JDK1.5才放出来,与此同时,Spring早期版本主要也还是以xml配置为主,Guice在那时就支持全注解配置,以当时的眼光来看,很前沿了。
接下来,我们就来仔细了解下Guice的用法。
核心理念
在开始讲之前,我说下我对IOC框架的理解先。很多时候,可以简单地说,IOC容器是一个map,一个放东西的地方,就像一个中药房,每个格子里会放一种药材,而每个格子上,有一个标签,来说明里面放的是什么药材。
既然是放东西的地方,核心就是两个部分,怎么放,放的时候,可能就要考虑到后续怎么找的问题。比如,如果你打算只支持根据物品的类型来找,那你要考虑到:如果这个类型的物品有多个,要怎么办?怎么区分这多个物品?
如果你打算解决这个问题,那你可能就会想:那我放的时候,再给这些物品取个名字吧,免得多个相同类型的物品,分不清。
甚至呢,你可能会考虑,物品的权限隔离,比如,物品上再加个存放人的字段,以后取得时候,就只能:自己取自己的,不能取别人的。
反正,最终还是看需求,一般来说,像我们spring这种,按类型就差不多了,一个类型多个实现的时候,再根据名字区分一下就ok。
而Guice呢,我这边会重点讲解:怎么存。至于取,可能还分成两种,依赖注入和直接从容器中取。但是依赖注入的底层实现,也是:发现我依赖的某个东西没有,就去容器里取。
所以,取东西,我们只需要关注:直接从容器中怎么获取就行;我这边就不会特别关注依赖注入的问题。
Guice中,存东西的多种方式
概览
存东西,在Guice的文档里,名词叫做Binding,中文就是绑定吧。
https://github.com/google/gui...
绑定是什么意思,就是我最终可能需要从容器中获取ClassA类型的对象。既然要取,那还得先存,存的时候,我就要建立绑定:ClassA --》该Class类型对象的获取方式。
其实还是很简单的。下边就跟着我的代码例子,我们来看看。
以下全部的代码,都在:
https://gitee.com/ckl111/mave...
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 发布!