接口是为解决松耦合、可替换、多实现和契约统一而设计，约定“能做什么”而非“是什么”，聚焦能力声明、支持角色组合、依赖抽象、便于测试，应按实际需求适时引入。
接口在Java OOP中不是为了“定义模板”而存在，而是为了解决松耦合、可替换、多实现、契约统一这几类实际问题。它不描述“是什么”，而是约定“能做什么”。用对了，代码更易扩展；用错了，反而增加冗余。
需要统一行为规范，但实现方式千差万别
当多个类必须提供相同能力（比如“保存”“计算”“渲染”），但内部逻辑完全不同（文件保存 vs 数据库保存 vs 内存缓存），就该抽一个接口。JDK里的Runnable、Comparable、Predicate都是典型——它们只管声明方法签名，不管你怎么写。
- 例如：支付模块里有微信支付、支付宝、银行卡支付，都实现PaymentProcessor接口，上层业务只需调用process()，无需关心具体渠道
- 关键点：接口方法应聚焦“能力”，避免掺杂状态或实现细节（如不要加setApiKey()这种配置方法）
想让类同时具备多种角色，又不想被单继承限制
Java类只能单继承，但可以实现多个接口。这让你能灵活叠加职责——一个类既是“可序列化”的，又是“可比较的”，还是“可监听的”，互不干扰。
- 比如TreeSet内部元素既要能排序（实现Comparable），又要能自定义比较逻辑（接收Comparator），靠的就是接口组合
- 注意：别为了“看起来高级”硬凑多个接口，每个接口应代表一个清晰、内聚的角色（单一职责）
框架或模块间需要解耦，依赖抽象而非具体实现
当你写工具类、SDK或中间件时，使用者不该依赖你的某个具体类（比如MyLoggerI 
- Spring大量使用接口：Dao层用UserRepository，Service层只依赖它，底层换MyBatis或JPA都不影响
- 技巧：接口名建议用名词+er/able/ible（如Configurable、Retryable），避免动词开头（如DoSomething）
需要编写可测试、可模拟（Mock）的代码
单元测试中，你很难直接测依赖外部系统（数据库、HTTP服务）的类。但如果它依赖的是接口，就能用Mockito等工具快速构造模拟实现，专注验证逻辑本身。
- 例如：订单服务依赖InventoryService接口查库存，测试时Mock它返回“有货”或“缺货”，不用真连库存系统
- 提醒：接口不应过度设计——如果某个类永远只有一种实现，且无替换计划，先不用急着抽接口；等真实变化出现再重构更稳妥
基本上就这些。接口不是越多越好，也不是越早加越好。它真正起作用的时候，是当你发现“同样的调用，背后想换几种做法”“好几个类都要做同一件事但方式不同”“别人要用你的代码，但你不希望他们绑死在你的实现上”——这时候，接口就是最自然的解决方案。
