接口解耦模块的核心是业务代码只依赖接口契约而非具体实现，通过窄而专的接口（单一职责、方法≤3、参数≤2）、依赖注入、运行时替换和可预测方法设计实现真解耦。
接口解耦模块的核心，是让业务代码只认“它能做什么”，不关心“它怎么做”。只要接口契约不变，背后实现随时可换，业务逻辑一行都不用动。
定义窄而专的接口
一个接口只承担单一职责，方法数控制在 3 个以内，参数尽量不超过 2 个。这不是限制，而是为了划清边界。
- 比如消息发送，只定义 MessageSender 接口，含 send(Message msg) 方法
- 重试策略、失败记录、限流控制这些，都该拆成独立接口（RetryPolicy、DeliveryLog、RateLimiter）
- 避免把 send()、retry()、log() 塞进同一个接口——职责一混，新增一种渠道就得改一堆类
- 接口里别放常量（如 MAX_RETRY = 3），那是实现细节，应由具体类自己管理
依赖接口，而非实现类
业务类构造器中接收接口类型，所有具体实现由外部注入。这是解耦的物理基础。
Java注释规范Skills
下载
当用户要求为 Java 代码添加注释、修改注释、审查注释、整理注释格式，或要求按照代码注释规范处理 Java 文件时，使用本技能。本技能用于统一生成和维护 Java 类注释模板、按 Git 对比 release 判断版本号、补充每行代码上方中文块注释、调整注释空行规则，并保持 Java 文件 UTF-8 无 BOM 编码。典型触发场景包括：补充类注释、更新 @version、检查 @author 来源、整理行尾注释、把注释放到代码上一行、检查注释是否符合规范、构建前检查 Java 注释风格。
- 正确写法：public OrderProcessor(NotificationService service)，service 是接口类型
- 错误写法：new EmailService() 出现在业务方法里；或用 if-else 判断类型再 new 对象
- 没 Spring 时，可用工厂类统一创建（NotificationServiceFactory.get("sms")），调用方仍只认接口
- 测试时直接传入 Mockito.mock(MessageSender.class)，验证是否调用了 send，而不是怎么发的
运行时替换不惊动业务代码
只要新旧实现类都遵守同一接口，系统就能无缝切换。编译期无感知，才是真解耦。
立即学习“Java免费学习笔记（深入）”；
- 订单服务依赖 UserRepository 接口，当前用 JdbcUserRepository，明天换成 CacheUserRepository（内部包装 JDBC），UserService 完全不用改
- 事件发布用 EventPublisher 接口，背后是 Kafka 还是内存队列，业务模块完全不知情
- 上线前临时切支付渠道？只需改配置或注入对象，核心流程代码零修改
确保接口方法可预测、可测试
接口方法的行为必须完全由入参决定，不能偷偷读配置、静态变量或 ThreadLocal。
- 所有外部依赖（如 HttpClient、RedisTemplate）必须通过构造函数注入，不能在方法里 new 或静态调用
- 如果单元测试中 messageSender.send(msg) 报 NullPointerException，大概率是方法里用了未注入的私有字段
- 同步锁、IO 操作、复杂计算不属于接口契约，若必须做，需在文档中明确说明，否则调用方无法预期行为
