目录

1.SPI概念

1.1 从面向接口编程说起

1.2 “接口”位于“调用方”所在的“包”中

1.3 “接口”位于“实现方”所在的“包”中

1.4 “接口”位于独立的“包”中

1.5 API和SPI的转换关系

2.SPI 开源案例

2.1 JDK SPI案例

1.SPI概念

1.1 从面向接口编程说起

我们在“调用方”和“实现方”之间引入了“接口”，上图没有给出“接口”应该位于哪个“包”中，从纯粹的可能性上考虑，我们有三种选择：

1. “接口”位于“调用方”所在的“包”中。
2. “接口”位于“实现方”所在的“包”中。
3. “接口”位于独立的“包”中。

下面让我们依次分析这三种可能性，如果现实中确实有这种可能性，不如我们就为其起个名字以方便交流。

1.2 “接口”位于“调用方”所在的“包”中

我们先想象一个场景，以仓储的接口为例：

我们将“仓储接口”放置于“领域层”这个“包”中，实现放在一个独立的“包”中，我们看DDD大师的实现都是这样子，现在来思考一下为什么这么做。

“领域层”的“领域服务”会依赖“仓储接口”，“仓储接口”也会依赖“聚合根”，这两者都是除了“实现依赖”之外的依赖关系，如果将“接口”放到“仓储实现”中就丧失了面向接口编程的意义（编译也不会通过），如果放到“独立层”中呢？会编译不通过，出现双向依赖了。

对于类似这种情况下接口，我们将其称为“SPI”，全程为：service provider interface，“SPI”的规则如下：

1. 概念上更依赖调用方。
2. 组织上位于调用方所在的包中。
3. 实现位于独立的包中。
4. 常见的例子是：插件模式的插件。