SPI和普通设计模式区别

背景和价值
- - 1. 扩展主体：框架外部 vs 内部
  - 2. 接口与实现的绑定方式：“隐式约定” vs “显式编码”
  - 3. 设计目标：“开放给外部扩展” vs “内部逻辑解耦”
  - 一句话总结

背景和价值

SPI（Service Provider Interface）的扩展机制与普通设计模式（如策略模式、工厂模式）的本质区别，在于扩展的“主动性”和“边界”——SPI是一种“框架主导、外部被动实现”的扩展模式，而普通设计模式是“内部主动定义、内部实现”的扩展方式。具体可从三个核心维度区分：

普通设计模式：扩展逻辑由框架/系统内部定义和实现。
例如策略模式，PaymentStrategy接口和AlipayStrategy、WechatPayStrategy实现类通常都在同一个系统内部，扩展新策略需要修改系统源码（新增实现类并在工厂中注册）。扩展的主动权在系统自身。
SPI：扩展逻辑由框架/系统外部（第三方、业务方）实现。
框架只定义SPI接口（如JDK的java.sql.Driver），具体实现由外部厂商（如MySQL驱动、PostgreSQL驱动）提供，框架通过约定的加载机制（如扫描META-INF/services）自动发现并加载外部实现。扩展的主动权在框架之外的参与者。

普通设计模式：接口与实现的绑定是硬编码的、显式的。
例如工厂模式中，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的驱动实现，框架无需修改任何代码即可支持新实现。

普通设计模式：核心目标是解决系统内部的逻辑耦合，提升内部代码的可维护性。
例如策略模式分离“算法定义”和“算法实现”，让内部逻辑更清晰；工厂模式封装对象创建逻辑，避免调用方直接依赖具体实现。这些模式的扩展能力是“内部优化的副产品”，不支持外部参与者无感接入。
SPI：核心目标是构建“框架-外部实现”的协作标准，允许外部在不修改框架源码的前提下扩展功能。
它本质是一种“框架对外开放的协议”，例如：
- 日志框架SLF4J定义SPI接口，允许Logback、Log4j等实现接入；
- 电商中台定义PaymentProvider SPI，允许各业务线自行实现个性化支付逻辑，中台无需感知具体实现。