接口适配通过抽象契约与运行时委托实现解耦，采用对象适配器封装调用、集中转换逻辑，并结合spi自动发现适配器，避免类适配器引发的classloader隔离问题。
Java 插件化架构中，接口适配不是简单的类型强转，而是通过抽象契约 + 运行时委托实现模块解耦。核心在于：插件提供方定义自己的服务接口（如 PluginService），宿主系统只依赖统一的 ExtensionPoint 接口；类型转换逻辑实际发生在适配器层，而非 cast 表达式里。
插件接口与宿主接口不兼容时，用对象适配器封装调用
这是最常用、最安全的方式。宿主不继承插件类，而是持有一个插件实例引用，在适配器中完成方法映射和参数转换：
- 定义宿主期望的扩展点接口（目标接口）：
public interface ExtensionPoint { void execute(Map<string object> context); }</string> - 插件实现自有接口（适配者）：
public interface PluginService { void run(String taskId, Config cfg); } - 编写适配器（组合方式）：
public class PluginServiceAdapter implements ExtensionPoint {<br> private final PluginService plugin;<br> public PluginServiceAdapter(PluginService plugin) { this.plugin = plugin; }<br> @Override<br> public void execute(Map<string object> context) {<br> String taskId = (String) context.get("taskId");<br> Config cfg = convert(context); // 类型转换逻辑在此集中处理<br> plugin.run(taskId, cfg);<br> }<br>}</string>
避免使用类适配器，尤其在热加载/卸载场景下
类适配器（继承 + 实现）会导致插件类与宿主类产生编译期强依赖，且在 ClassLoader 隔离环境下极易引发 NoClassDefFoundError 或 IllegalAccessError。插件化强调运行时动态加载，对象适配器天然支持不同 ClassLoader 实例间的桥接。
- 插件 jar 由独立
URLClassLoader加载，其PluginService类与宿主不在同一命名空间 - 若用
class PluginAdapter extends PluginServiceImpl implements ExtensionPoint，宿主无法直接 new 出该类（类不可见） - 正确做法是：宿主通过反射或 SPI 获取插件实例后，再包装进适配器——转换逻辑与类加载解耦
类型转换逻辑应集中、可配置、可扩展
插件输入输出常含 JSON、Map、DTO 等异构结构，硬编码转换易出错且难以维护。建议将转换职责分离：
- 定义统一上下文载体：
ExtensionContext（封装原始数据 + 元信息 + 转换策略标识） - 引入轻量级转换器注册表：
ConverterRegistry.get("plugin-v2").convert(context) - 对常见类型（如
String → LocalDateTime、Map → PluginConfig）提供默认实现，允许插件按需覆盖 - 转换失败时抛出
ExtensionConversionException，由宿主统一降级或告警，不向插件暴露内部类型细节
结合 Java SPI 和 ServiceLoader 实现自动适配发现
让插件声明自己提供的适配器，而非由宿主硬编码绑定：
- 插件 jar 的
META-INF/services/com.example.ExtensionAdapter文件写入：com.myplugin.MyPluginAdapter - 宿主启动时扫描所有
ExtensionAdapter实现类：ServiceLoader.load(ExtensionAdapter.class).forEach(adapter → registry.register(adapter)); -
ExtensionAdapter接口含boolean supports(Class> pluginType)方法，用于运行时匹配 - 这样新增插件只需打 jar 包 + 放 service 文件，无需修改宿主代码
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
