Java接口解耦的核心在于“谁持有接口、谁负责创建实现”，而非仅定义接口；它强制分离契约与实现，避免单继承限制，支持多实现与依赖倒置，粒度应内聚单一，创建逻辑须外移。
Java 接口本身不提供实现，但它是解耦最轻量、最有效的机制——关键不在“定义接口”，而在“谁持有接口、谁负责创建实现”。
为什么用 interface 而不是 abstract class 来解耦
接口强制分离契约与实现，避免继承带来的强依赖和单继承限制。比如日志模块：你定义 Logger 接口，业务代码只依赖它；后续可自由切换 Slf4jLogger、Log4jLogger 或 MockLogger，无需修改任何调用方。
-
interface支持多实现（一个类可 implements 多个接口），abstract class会绑定具体父类，破坏横向替换能力 - 接口默认方法（
default）仅用于向后兼容，不应作为核心逻辑载体——否则实现类容易绕过统一行为约束 - 若需共享状态或构造逻辑，应通过组合（如注入
Config对象）而非继承解决
依赖倒置：让高层模块持有接口，而不是实现类
常见错误是“先写实现，再抽接口”，结果接口变成实现的镜像，毫无解耦价值。正确做法是：从调用方视角反推需要什么能力。
例如订单服务需要“发通知”，就定义：
立即学习“Java免费学习笔记（深入）”；
public interface NotificationService {
void send(String recipient, String content);
}
然后让订单服务构造时接收该接口：
public class OrderService {
private final NotificationService notifier; // 持有接口，不关心实现
public OrderService(NotificationService notifier) {
this.notifier = notifier;
}
}
- 实现类（如
EmailNotificationService）由外部容器或工厂创建，业务代码完全隔离 - 单元测试时可直接传入
new MockNotificationService()，无需启动邮件服务 - 若用
new EmailNotificationService()在OrderService内部硬编码，解耦即失效
Spring 中用 @Autowired 注入接口时的典型陷阱
Spring 默认按类型（byType）注入，当多个实现类存在时会抛 NoUniqueBeanDefinitionException。
- 用
@Qualifier("emailNotifier")显式指定 Bean 名，别依赖默认类名（如emailNotificationService可能被 Spring 自动截断） - 接口只有一个实现时，
@Primary可设为首选，但多人协作时易被忽略，建议优先用@Qualifier - 避免在接口上加
@Component——接口不能被 Spring 实例化，加了也没用，还可能误导新人 - 若需运行时动态选实现（如按地区切通知渠道），用
ObjectProvider或策略模式封装，别硬写 if-else 判断实现类类型
接口粒度控制：过粗难 mock，过细增维护成本
一个接口只表达一种内聚能力。比如把 save()、sendEmail()、generateReport() 全塞进 OrderManager 接口，会导致测试时不得不 mock 所有方法，哪怕只测保存逻辑。
- 推荐“单一职责+动词命名”：如
OrderRepository（专注数据存取）、OrderNotifier（专注通知）、OrderValidator（专注校验） - 接口方法参数尽量用 DTO 或基础类型，避免暴露领域实体（如
OrderEntity），否则实现变更会牵连所有调用方 - 不要为“未来可能扩展”提前加空方法——YAGNI 原则：等真有第二个实现再提炼公共接口
真正卡住解耦效果的，往往不是接口定义是否漂亮，而是谁在 new 实现类、谁在决定用哪个实现——这些决策点必须外移，且对业务代码不可见。
