如何借助接口实现插件式架构

接口是插件式架构最轻量稳定的核心契约，需满足纯抽象、参数返回值限于POD或JDK基础类型、生命周期责任明确三硬约束，且加载时接口类必须由宿主加载以避免ClassCastException。

接口是插件式架构最轻量、最稳定的核心契约。它不携带实现、不绑定类加载器、不依赖运行时反射，只定义“能做什么”，让宿主与插件在编译期就达成一致，又在运行时保持解耦。

接口设计必须满足三个硬约束

不是随便写个 interface 就能当插件契约——它得扛得住跨模块、跨类加载器、跨版本的边界压力：

• 纯抽象，无默认方法：JDK 8+ 的 default 方法在多 ClassLoader 场景下易引发兼容问题，尤其热部署或 OSGi 环境；接口应只含 public abstract 方法和常量
• 参数返回值限于 POD 或 JDK 基础类型：禁止 std::string（C++）、std::shared_ptr（C++）、List<T>（Java）、Task（C#）等带内存模型或泛型擦除的类型；推荐用 String、int、double、byte[]、Map<String, Object> 等跨边界安全的载体
• 生命周期责任明确：接口需包含 init() / shutdown() 或 create() / destroy() 成对方法，避免资源泄漏；销毁逻辑不能由宿主 new/delete 或 GC 承担，必须交还插件自己释放

动态加载的关键不在“找类”，而在“找接口实例”

加载失败多数不是代码问题，而是类加载链断裂。核心原则：接口类必须由宿主加载，插件类由插件类加载器加载，强转才有效。

• Java 中用 URLClassLoader 时，parent 必须设为宿主 ClassLoader，否则接口类被重复加载，强转必抛 ClassCastException
• C# 中用 Assembly.LoadFrom 加载插件 DLL 后，需用宿主已知的接口类型（如 IPlugin）接收 Activator.CreateInstance 返回值，而非插件内部定义的派生类型
• C++ 中不传对象指针，而传 extern "C" 工厂函数指针，返回 void* 后由宿主 reinterpret_cast<IPlugin*> —— 虚表布局风险由此规避

避免把接口当“万能胶”，要配合策略层使用

接口解决“能不能调”，但不解决“该不该调”“谁先调”。真实系统中需叠加一层策略控制：

• 给每个插件实现加 getOrder() 或 getPriority() 方法，宿主收集后排序，不用依赖 classpath 加载顺序
• 用 @ConditionalOnProperty（Spring）、配置文件开关、或环境变量控制 enable/disable，而不是靠删 JAR 包来“卸载”
• 对可能失败的插件调用做 try-catch + fallback，默认实现兜底，防止单点故障拖垮整个流程

接口本身不复杂，但它是插件系统里最不容妥协的一环。稳住接口，才能让扩展不变成维护噩梦。