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

接口升级，这几乎是每个稍微有点规模的项目都会遇到的头疼事。问题在于，接口本身并没有内置什么“版本隔离”的开关。但这并不意味着我们只能硬着头皮改。实际上，通过一些巧妙的设计手法，完全可以让新旧两套逻辑和平共处，各司其职。

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

用接口拆分替代版本标记

一种常见的做法是避免在接口名里直接写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。
• 两个接口可以由同一个产品服务实现，但调用方只看到自己需要的部分，互不干扰地演进。

说到底，这件事听起来有点抽象，但本质很简单：接口隔离不是为了制造更多接口，而是让每个接口的职责边界清晰、调用方明确、变更的影响范围可控。版本隔离的真正本质，其实就是控制变化的影响范围——从这个角度看，最精简的接口，就是最坚固的防火墙。