接口应聚焦业务契约而非实现细节：参数用通用领域概念，返回值用标准封装，禁止暴露三方SDK类型；依赖倒置要求高层模块定义接口、低层实现；扩展新渠道应采用策略模式而非if-else；需通过契约测试保障各实现行为一致。
接口不是为了写而写，是为替换留出口
Java里定义一个 PaymentService 接口不难，难的是它真能被不同实现无缝换掉。常见错误是把接口写成“当前实现的抽象副本”——比如方法里硬塞了 AlipayOrderDTO 参数，结果微信支付根本没法实现这个接口。
真正可扩展的接口要满足：参数尽量用领域内通用概念（如 Money、OrderId），返回值用简单类型或标准封装（Result<string></string>），不暴露任何三方 SDK 类型。
- 避免在接口中引用具体 SDK 包名，如
com.alipay.api.response.AlipayTradePayResponse - 如果必须传原始数据，用
Map<string object></string>或自定义泛型容器，而非三方对象 - 接口方法命名聚焦业务动作，比如
pay(ChargeRequest request)，而不是alipayPay(...)或doWechatPay(...)
依赖倒置 ≠ 用 Spring @Autowired 就完事
很多人以为加个 @Service + @Autowired 就算遵守了依赖倒置，其实只是把“new 具体类”换成了框架注入——但模块间耦合依然存在：支付模块强依赖订单模块的 OrderRepository，导致改订单模型就得动支付逻辑。
关键在“谁该依赖谁”。正确做法是：高层模块（如支付服务）只依赖自己定义的接口（OrderQuery），由低层模块（订单服务）去实现它；Spring 配置只是把实现类挂上去，不是倒置的主体。
立即学习“Java免费学习笔记（深入）”；
- 接口定义放在调用方模块（比如支付模块的
src/main/java/com.example.pay/infra/OrderQuery.java） - 实现类放在被调用方模块（订单模块的
OrderQueryImpl），并通过@Component或手动注册进 Spring - 禁止跨模块直接 import 对方的 service 类，所有交互走本模块定义的接口
扩展新渠道时，别碰老代码的 if-else 分支
加个抖音支付，就往原有 if (type == ALI) {...} else if (type == WECHAT) {...} 里塞新分支？这是最典型的反模式。一旦分支超过 3 个，维护成本指数上升，测试覆盖也容易漏。
真正的扩展点是工厂 + 策略。用 PaymentStrategy 接口统一行为，每个渠道一个实现类，再通过 PaymentStrategyFactory 按 type 返回对应实例——新增渠道只需加一个类和注册，老代码一行不动。
- 工厂类不要用 if-else，改用 Map 初始化：
strategies.put("douyin", new DouyinPaymentStrategy()) - 策略类构造函数里不做重逻辑初始化，避免启动慢或单例污染
- 注意 Spring 的 Bean 名称冲突：多个
@Service实现同一接口时，要用@Qualifier显式指定
测试时最容易忽略的边界：接口与实现的契约漂移
开发后期，接口没变，但某个实现悄悄改了行为——比如 refund() 方法原来承诺“失败时抛 RefundException”，新写的 PayPal 实现却返回 null。调用方没做空判断，线上就 NPE。
这不是靠人盯，而是靠契约测试。在接口模块写一个抽象测试类，用 @Test 覆盖所有公共行为，让每个实现类都继承它：
abstract class PaymentServiceContractTest {
protected abstract PaymentService createInstance();
@Test
void refund_should_throw_exception_when_order_not_found() {
assertThrows<RefundException>(() -> createInstance().refund("nonexistent"));
}
}
这样每次新增实现，就必须过这套测试，否则编译不过。
接口的稳定性比实现重要得多；一旦发布，改接口就是伤筋动骨。宁可多拆几个小接口，也不要往老接口里塞新方法。
