电子说
八股文背多了,相信大家都听说过一个词, SPI扩展 。
有的面试官就很喜欢问这个问题,SpringBoot的自动装配是如何实现的?
基本上,你一说是基于spring的SPI扩展机制,再把spring.factories
文件和EnableAutoConfiguration
提一下,那么这个问题就答的八九不离十了。
就像四五年前,我去面试的时候被问到这个问题,SPI动态扩展机制这几个词从嘴里一说出来,就把面试官唬的一愣一愣的。可能他们也没见过这么能装逼的,一句话能简简单单说明白,非要拽一个听上去很高大上的词。
话说回来,被唬住的可不止是面试官,其实还有我自己。至于SPI扩展究竟是个啥,是怎么实现的,我当时也根本不明白。
不过现在的面试就是这样,对线八股文,要想唬住面试官,就得先唬住自己。
那么我们今天暂且不提spring的SPI扩展,先来看看java本身自带的SPI扩展机制是怎么一回事。
SPI的全称是Service Provider Interface
,翻译过来就是 服务提供者的接口 ,它所实现的其实是一种服务的发现机制。
这么说起来可能还是有点不好理解,我举个例子来类比一下。
在spring项目中,写service层代码前,会约定俗成的会添加一个接口层。然后通过spring中的依赖注入,可以借助@Autowired
等方式注入这个接口的实现类的实例对象,之后对于service的调用一般也基于接口操作。
简单形容就是这样的:
如图所示,接口、实现类都是由服务提供方提供,我们可以把controller看作服务调用者,调用方只管调用接口就可以了。
虽然也有声音认为,大部分情况下service只有一个实现类,接口层显得有些多余。但是在《Head First Design Patterns》这本书中,大佬们还是建议过:
Program to an interface, not an implementation.
没错,就是常说的 要面向接口编程 。至于好处,也不外乎是降低耦合度、方便日后扩展、提高了代码的灵活性和可维护性等等。
在上面这个例子里,这个接口层和其中的方法我们可以称之为 API ,而我们要讨论的SPI和它相比,有类似也有差异,还是先看图:
简单来说,就是服务的调用方定义一个接口规范,可以由不同的服务提供者实现。并且,调用方能够通过某种机制来发现服务提供方,并通过接口调用它的能力。
通过对比,我们可以看出它们虽然都有着接口这一层面,但还是有很大的不同:
API中的接口是服务提供者给服务调用者的一个功能列表,而SPI中更多强调的是,服务调用者对服务实现的一种约束,服务提供者根据这种约束实现的服务,可以被服务调用者发现。
说白了,Java中的SPI实现的就是,你按我的接口规范实现服务,我就能通过某种机制为这个接口寻找到这个服务。
这么说起来可能还有些抽象,下面我们举一个例子,类比具体描述一下这个过程。
说起智能家居系统,大家现在都比较熟悉了,只要是相同品牌下的产品,连上wifi就能够通过手机app控制了,非常方便。
虽然产品不断更新换代,型号更新层出不穷,但是同种家电在app上操作起来,功能一般都是一样的。就拿空调来说,我们在app上操作起来一般也就三个主要功能: 开关 , 选模式 , 调节温度 。
假设我现在在客厅、卧室、书房安装了3款不同型号的空调,并把它们都接入到了我app中,那么之后的操作都是相同的几个按键,简单粗暴。
思考一下,无论是开关还是调温,都是通过app去调用设备的接口罢了,那么如果不同型号的空调各写各的接口,后端app在开发的时候光对接接口都麻烦的要死。
解决方法也很简单,我先定义一套接口规范,不管你以后什么型号的空调,都按我的规范来实现接口。以后只要我能发现你的设备,那么都可以按相同的方法来调用接口。
那么下面就先来定义这么一套接口规范,如果你以后想要接入智能家居系统,那么就要遵循这个规范来开发接口。
新建一个项目作为标准,就叫aircondition-standard
好了,然后创建一个接口。除了3个操作以外,我们再添加一个获取空调型号的方法。
public interface IAircondition {
// 获取型号
String getType();
// 开关
void turnOnOff();
// 调节温度
void adjustTemperature(int temperature);
// 模式变更
void changeModel(int modelId);
}
这个接口后面要给服务的实现方来使用,用maven把它打成jar包:
mvn clean install
之后服务提供者在项目中就可以引入这个jar包了,有了这套规范,就保证了产品后期不管怎么更新换代,都能接入到系统来。
制定并发布完规则后,挂式空调作为第一个服务提供者就来了,新建一个项目aircondition-hanging-type
,并引入刚才打好的jar包:
<dependency>
<groupId>com.cn.hydra<span class="hljs-name"groupId>
<artifactId>aircondition-standard<span class="hljs-name"artifactId>
<version>1.0-SNAPSHOT<span class="hljs-name"version>
<span class="hljs-name"dependency>
创建服务类,并实现前面定义的接口:
public class HangingTypeAircondition
implements IAircondition{
public String getType() {
return "HangingType";
}
public void turnOnOff() {
System.out.println("挂式空调开关");
}
public void adjustTemperature(int i) {
System.out.println("挂式空调调节温度");
}
public void changeModel(int i) {
System.out.println("挂式空调更换模式");
}
}
在项目的resources
的目录下,创建META-INF/services
目录,然后以前面定义的接口名com.cn.hydra.IAircondition
创建文件,并在文件中写入实现类的全限定名。
com.cn.hydra.HangingTypeAircondition
整个项目结构非常简单:
这样,一个服务方的简单实现就搞定了,用maven打成jar包,之后就可以提供给调用方使用了。
同理,我们可以再创建一个立式空调的项目aircondition-vertical-type
,也只创建一个服务类:
public class VerticalTypeAircondition
implements IAircondition{
public String getType() {
return "VerticalType";
}
public void turnOnOff() {
System.out.println("立式空调开关");
}
public void adjustTemperature(int i) {
System.out.println("立式空调调节温度");
}
public void changeModel(int i) {
System.out.println("立式空调更换模式");
}
}
还是按上面的命名规则,创建一个配置文件:
com.cn.hydra.VerticalTypeAircondition
同样,打成jar包就完事了,至于服务调用者如何去发现和调用这两个服务,下面详细再说。
全部0条评论
快来发表一下你的评论吧 !