面向接口编程是为了替换实现而不改调用方，核心是依赖抽象而非具体，聚焦契约而非细节，适用于多实现或需模拟的场景，避免接口泛滥。
面向接口编程不是为了“看起来高级”，而是为了替换实现不改调用方
当你写 new ArrayList() 直接实例化具体类，后续想换成 LinkedList 或自定义缓存版列表时，就得逐个修改所有 new 处——这违反开闭原则。而声明为 List 类型，只依赖 List 接口定义的方法，底层换实现时调用方代码完全不动。
接口定义契约，而非功能细节
一个 PaymentService 接口只该有 process(PaymentRequest) 和 refund(RefundRequest) 这类业务动作，不该暴露 setRetryTimes(int) 或 useMockMode() 这种配置细节。后者属于实现类的内部策略，塞进接口会导致所有实现被迫支持、调用方被污染。
- 接口方法应聚焦「做什么」，而非「怎么做」或「怎么配」
- 避免在接口中加默认方法来“方便实现”，除非该逻辑是领域共识（如
Collection.isEmpty()） - 接口名用名词或动名词（
OrderValidator、LoggingAspect），不用DoSomethingInterface这类冗余后缀
Spring里@Autowired按接口注入，不是按实现类
Spring 的依赖注入默认按类型（byType）匹配，所以 @Autowired private UserService userService; 能成功注入，是因为容器里存在实现了 UserService 接口的 Bean（比如 UserServiceImpl）。如果你直接写 @Autowired private UserServiceImpl userServiceImpl;，不仅耦合具体类，还会在多实现时失败。
public interface UserService {
User findById(Long id);
}
@Service
public class UserServiceImpl implements UserService {
@Override
public User findById(Long id) {
// 实际查询逻辑
}
}
- 测试时可轻松用
Mockito.mock(UserService.class)替换真实服务 - 若某天需要加审计日志，只需新增
AuditingUserService实现同一接口，再通过@Primary或@Qualifier控制注入，原业务代码零改动 - 注意：不要为每个实现类单独定义接口（如
UserServiceImpl对应UserServiceImplInterface），那是接口泛滥
容易忽略的边界：接口不是万能胶，过度抽象反而害人
不是所有地方都适合抽接口。比如工具类 StringUtils、DTO 对象、或仅有一个实现且确定永不变的组件（如 LocalDateTimeUtils），硬加接口只会增加跳转成本和理解负担。
立即学习“Java免费学习笔记（深入）”；
- 接口应出现在「可能有多种实现」或「需要被模拟/替换」的位置，例如数据访问层（
OrderRepository）、外部服务适配（SmsClient）、策略分支（PricingStrategy） - 当发现接口里方法长期只有 1 个实现、且没人写单元测试去 mock 它，就该质疑这个接口是否存在必要
- 接口方法签名一旦发布，修改成本极高（要兼顾所有实现），所以设计时宁少勿多，优先考虑组合而非继承式扩展
