面向对象接口：如何通过接口实现版本隔离

接口不直接提供版本隔离，但可通过拆分职责、默认方法、适配器和按角色定制等策略实现新旧功能解耦共存，核心是控制变化影响范围。

接口本身不直接提供“版本隔离”能力，但可以通过合理设计接口结构、命名、继承关系和实现策略，间接达成不同版本功能的解耦与共存。关键不是给接口加版本号，而是让新旧行为互不干扰、按需选用。

用接口拆分替代版本标记

避免在接口名中硬编码 v1、v2（如 UserServiceV2），而应按职责或能力维度拆分：

• 把通用能力（如 findById、listAll）抽成基础接口 UserQueryable
• 把新增字段校验、异步通知等扩展能力单独定义为 UserValidatable 或 UserNotifiable
• 旧系统只依赖 UserQueryable；新模块可组合多个小接口，无需修改原有实现

通过默认方法支持渐进升级（Java/Go/C#）

在语言支持默认方法的前提下，可在不破坏已有实现类的前提下追加能力：

• 在原有接口中添加带默认实现的新方法（如 getDisplayName()），老实现类自动获得兼容行为
• 新业务类可选择重写该方法以提供定制逻辑，不影响老调用方
• 注意：Python 的 ABC 不支持默认方法，需改用组合或适配器模式

用适配器桥接新旧契约

当底层协议或数据结构发生不兼容变更时，用适配器封装转换逻辑：

• 定义新接口 OrderProcessorV2，含字段 paymentMethodId
• 保留旧接口 OrderProcessor，含字段 paymentType
• 编写 OrderV1ToV2Adapter 实现 OrderProcessorV2，内部调用旧服务并做字段映射
• 上层模块按需注入适配器或原生实现，不感知版本差异

按消费者角色提供定制接口

同一业务实体对不同调用方暴露不同能力集，天然形成逻辑“版本”隔离：

• 面向前端展示的 ProductSummary 接口只含 id、name、price
• 面向风控系统的 ProductRiskDetail 接口额外包含 supplyChainTrace、certValidity
• 两者都可由同一个产品服务实现，但调用方只看到自己需要的部分，互不影响演进

不复杂但容易忽略：接口隔离不是为了造更多接口，而是让每个接口背后的责任清晰、使用者明确、变更边界可控。版本隔离的本质，是控制变化的影响范围——而最小接口就是最有效的防火墙。