依赖注入与面向接口编程本质统一，均通过抽象契约解耦实现；接口是di前提，否则无法替换实现；构造器注入更安全，保障依赖不为空且支持不可变性；接口应围绕明确协作角色设计，避免过度拆分或臃肿。
Java依赖注入（DI）和面向接口编程不是两套独立方法，而是同一设计思想在不同层面的体现：用抽象契约解耦具体实现，让对象的创建与使用分离。
为什么接口是依赖注入的前提
没有接口，注入就失去意义——你只能注入某个具体类，而无法在不改代码的前提下替换实现。Spring 的 @Autowired 或 Guice 的 @Inject 注入的从来不是 UserServiceImpl 这样的类，而是它所实现的 UserService 接口。
- 若一个类直接
new UserServiceImpl()，它就硬编码了实现，无法被测试替换成MockUserService - 若构造函数参数声明为
UserService userService，那注入容器才可能把任意符合该接口的实例塞进来 - Spring 默认按类型匹配（
byType），所以同类型接口下只能有一个默认实现，否则要加@Qualifier指定名字
@Autowired 和构造器注入哪个更安全
构造器注入是推荐方式，它能保证依赖不为空，且天然支持不可变性；@Autowired 字段注入虽写法简洁，但隐藏了依赖关系，且在单元测试中必须手动 ReflectionTestUtils.setField() 或启用 Spring 上下文。
- 构造器注入让类本身可脱离 Spring 独立实例化：
new OrderService(new PaymentGatewayImpl(), new NotificationServiceStub())
- 字段注入导致类强依赖 Spring 容器，且无法通过 final 修饰符保护字段，容易在运行时出现
NullPointerException - 从 Spring 4.3 起，单构造器场景下可省略
@Autowired注解，但显式标注更清晰
接口定义多细才算合理
接口不是越多越好，也不是越小越好；它应围绕“一个明确的协作角色”来定义，而非按实现类机械拆分。比如 OrderRepository 不该拆成 SaveOrderPort、FindOrderPort，而应聚焦于领域语义：“订单怎么存取”，不是“存和查这两个动作”。
立即学习“Java免费学习笔记（深入）”；
- 过度细化接口（如每个方法一个接口）会导致实现类要实现十几个空方法，违背接口隔离原则的本意
- 一个接口包含 3–7 个内聚方法通常是合理的，关键看调用方是否总是需要它们一组出现
- 若某实现只用到接口中 20% 的方法，说明这个接口承担了多个职责，应该拆；若两个类总是一起被注入，说明它们可能属于同一抽象层次，可考虑合并或引入组合接口
真正难的不是写出接口或加上 @Autowired，而是判断哪些逻辑值得抽象、哪些变化点确实会发生、以及谁该为接口的稳定性负责。接口一旦发布，修改成本远高于实现类。
