- 背景和价值
- 1. 扩展主体:框架外部 vs 内部
- 2. 接口与实现的绑定方式:“隐式约定” vs “显式编码”
- 3. 设计目标:“开放给外部扩展” vs “内部逻辑解耦”
- 一句话总结
背景和价值
SPI(Service Provider Interface)的扩展机制与普通设计模式(如策略模式、工厂模式)的本质区别,在于扩展的“主动性”和“边界”——SPI是一种“框架主导、外部被动实现”的扩展模式,而普通设计模式是“内部主动定义、内部实现”的扩展方式。具体可从三个核心维度区分:
1. 扩展主体:框架外部 vs 内部
-
普通设计模式:扩展逻辑由框架/系统内部定义和实现。
例如策略模式,PaymentStrategy
接口和AlipayStrategy
、WechatPayStrategy
实现类通常都在同一个系统内部,扩展新策略需要修改系统源码(新增实现类并在工厂中注册)。扩展的主动权在系统自身。 -
SPI:扩展逻辑由框架/系统外部(第三方、业务方)实现。
框架只定义SPI接口(如JDK的java.sql.Driver
),具体实现由外部厂商(如MySQL驱动、PostgreSQL驱动)提供,框架通过约定的加载机制(如扫描META-INF/services
)自动发现并加载外部实现。扩展的主动权在框架之外的参与者。
2. 接口与实现的绑定方式:“隐式约定” vs “显式编码”
-
普通设计模式:接口与实现的绑定是硬编码的、显式的。
例如工厂模式中,PaymentFactory
需要明确通过if-else
或switch
判断条件,返回特定的Payment
实现类:public Payment createPayment(String type) {if ("alipay".equals(type)) {return new AlipayPayment(); // 显式依赖内部实现类} else if ("wechat".equals(type)) {return new WechatPayment();}return null; }
新增实现类后,必须修改工厂类的代码才能生效,否则框架无法感知新实现。
-
SPI:接口与实现的绑定是配置驱动的、隐式的。
框架通过预定义的规则(如文件路径、注解)自动发现实现类,无需硬编码。例如MySQL驱动实现JDK的Driver
接口后,只需在META-INF/services/java.sql.Driver
文件中写入实现类全路径:com.mysql.cj.jdbc.Driver
JDK的
ServiceLoader
会自动扫描该文件,加载MySQL的驱动实现,框架无需修改任何代码即可支持新实现。
3. 设计目标:“开放给外部扩展” vs “内部逻辑解耦”
-
普通设计模式:核心目标是解决系统内部的逻辑耦合,提升内部代码的可维护性。
例如策略模式分离“算法定义”和“算法实现”,让内部逻辑更清晰;工厂模式封装对象创建逻辑,避免调用方直接依赖具体实现。这些模式的扩展能力是“内部优化的副产品”,不支持外部参与者无感接入。 -
SPI:核心目标是构建“框架-外部实现”的协作标准,允许外部在不修改框架源码的前提下扩展功能。
它本质是一种“框架对外开放的协议”,例如:- 日志框架SLF4J定义SPI接口,允许Logback、Log4j等实现接入;
- 电商中台定义
PaymentProvider
SPI,允许各业务线自行实现个性化支付逻辑,中台无需感知具体实现。
一句话总结
普通设计模式是“系统自己管好自己的扩展”,SPI是“系统开放接口让别人来扩展自己”。前者是内部优化,后者是生态化协作。
例如:
- 若电商中台的支付方式只在内部迭代(如新增银联支付),用策略模式即可;
- 若允许外部商户接入自己的支付渠道(如商户A的自有支付系统),则必须用SPI,让外部实现者遵循中台定义的接口规范接入。