核心是业务模块只依赖接口而非实现类，接口应窄而专、职责单一，方法不超过3个、参数不超2个；依赖须通过构造器注入，禁止硬编码创建实例；运行时可无缝替换实现，接口方法需无状态、可测试且外部依赖全由构造函数注入。
核心是让业务模块只依赖接口，不依赖具体实现类。只要某段逻辑未来可能换实现（比如从发邮件换成发短信、从 MySQL 换成 Redis），它就必须抽成接口。
定义窄而专的接口
接口不是功能清单，而是职责契约。一个接口只管一件事，方法数建议不超过 3 个，参数尽量控制在 2 个以内。
- 例如消息发送，定义 MessageSender 接口，只含 send(Message msg) 方法；重试策略、日志记录应拆成独立接口（RetryPolicy、DeliveryLog）
- 避免把 send()、retry()、logFailure() 塞进同一个接口——这会把多个职责耦合在一起，新增一种发送方式时就得改一堆逻辑
- 接口里别放常量（如 MAX_RETRY = 3），那是实现细节，应由具体类自己管理
用构造器注入代替硬编码
业务类不能自己 new 实现类，也不能用 if-else 判断类型再创建对象。所有依赖必须通过外部传入。
- 正确做法：在业务类（如 OrderProcessor）的构造方法中接收接口类型（NotificationService service），由 Spring 容器或测试代码传入具体实现
- 错误写法：new EmailService() 出现在业务方法里；或 if (type.equals("sms")) { new SMSService() } 这类分支创建
- 没有 Spring 时，可用工厂类（NotificationServiceFactory.get("sms")）统一创建，调用方仍只认接口
运行时可替换，编译期无感知
更换实现不改业务代码，是解耦的直接体现。只要新旧实现类都遵守同一接口，系统就能无缝切换。
立即学习“Java免费学习笔记（深入）”；
- 例如订单服务依赖 UserRepository 接口，当前用 JdbcUserRepository，明天换成 CacheUserRepository（内部包装 JDBC 实现），UserService 一行代码都不用动
- 事件驱动场景下，EventPublisher 接口只暴露 publish(Event event)，背后是 Kafka 还是内存队列，业务模块完全不知情
- 测试时直接传入 Mockito.mock(MessageSender.class)，不 mock 具体类，验证的是“是否调用了 send 方法”，而非“怎么发的”
确保接口方法无状态且可测试
接口方法的行为必须完全由入参决定，不能偷偷读配置、静态变量或线程局部变量；所有外部依赖（如 HttpClient、RedisTemplate）必须通过构造函数注入。
- 如果单元测试中 messageSender.send(msg) 报 NullPointerException，大概率是接口方法里用了未注入的私有字段（如 private Config config）
- 接口方法不要做同步锁、IO 或复杂计算——这些属于实现细节，若必须做，要在文档里明确说明，否则调用方容易误用
