核心是让业务模块只依赖窄而专的接口，不依赖具体实现类；接口只管一件事、方法≤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")）统一创建，调用方仍只认接口
运行时可替换，编译期无感知
更换实现不改业务代码，是解耦的直接体现。只要新旧实现类都遵守同一接口，系统就能无缝切换。
- 例如订单服务依赖 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 或复杂计算——这些属于实现细节，若必须做，要在文档里明确说明，否则调用方容易误用
- Java 8+ 的 default 方法可用于补救小范围共性逻辑（如空值校验），但不能用来掩盖设计缺陷，比如把本该拆分的职责硬塞进 default 方法里
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
