面向接口编程的核心是依赖抽象契约而非具体实现，关键在于明确角色职责、隔离变化、提升可替换性与可测试性，需回答“谁用它、能做什么、边界在哪”，避免假抽象和接口泛滥。
面向接口编程的核心是把“依赖具体实现”变成“依赖抽象契约”，Java 通过 interface 提供了天然支持。关键不在于多写几个 interface，而在于用接口明确角色职责、隔离变化、提升可替换性与可测试性。
接口不是为了多态而多态，而是为了定义能力契约
一个好接口应该回答三个问题：谁用它？它能做什么？边界在哪？比如不是定义 UserService，而是先想清楚“用户登录”“校验手机号”“生成临时令牌”这些行为是否属于同一能力维度。若混杂业务逻辑与数据访问，就违背了单一职责。
- 接口名用名词或形容词+Ability/Service/Provider（如
TokenGenerator、OrderValidator），避免动宾结构（如CheckOrder） - 方法签名只暴露必要参数和返回值，不泄露实现细节（如不用
HashMap，改用Map；不暴露 JDBC Connection） - 接口中默认方法（
default）仅用于向后兼容或通用模板逻辑，不可替代具体实现类的职责
用依赖注入让接口真正“活”起来
声明接口只是第一步，运行时绑定实现类才能体现解耦价值。硬编码 new UserServiceImpl() 会让接口形同虚设。推荐结合构造器注入或 Spring 的 @Autowired：
public class OrderProcessor {
private final PaymentGateway paymentGateway;
private final NotificationService notificationService;
// 构造器强制依赖接口，杜绝空指针且便于单元测试
public OrderProcessor(PaymentGateway gateway, NotificationService notifier) {
this.paymentGateway = gateway;
this.notificationService = notifier;
}
}
- 避免在类内部 new 实现类，也不要用静态工厂方法隐藏依赖
- 测试时可直接传入 Mock 实现（如
new MockPaymentGateway()），无需启动容器 - 多个实现共存时（如
SmsNotificationService和EmailNotificationService），用策略模式或 Spring 的@Qualifier区分
接口演进要兼顾兼容性与表达力
接口一旦发布，修改成本高。新增功能优先用 default 方法或新接口继承老接口，而不是直接加方法——否则所有实现类编译失败。
立即学习“Java免费学习笔记（深入）”；
- 旧接口保持稳定，新需求走扩展路线：如原有
Storage接口只支持 save/load，新增加密需求可定义SecureStorage extends Storage - 若必须修改，优先考虑退化兼容：用 default 方法提供空实现或抛
UnsupportedOperationException，并加注释说明废弃路径 - 包路径反映语义层级，如
com.example.order.api放接口，com.example.order.internal放实现，从包结构上强化抽象与实现分离
警惕“接口泛滥”和“假抽象”陷阱
每个类配一个接口（如 UserDao + UserDaoImpl），但接口里只有 CRUD 方法，没有业务语义，这种抽象没有实际价值。真正的接口驱动设计，是从问题域出发反推契约。
- 先写测试用例，再根据测试需要的协作行为倒推出接口（TDD 驱动）
- 当两个类需要交换相同行为（如支付模块和退款模块都需“冻结资金”），才值得抽出公共接口
- 接口不应成为“实现类的镜像”，而应是“调用方视角的最小完备能力集”
不复杂但容易忽略：接口的价值不在语法层面，而在团队沟通和系统演进中降低理解成本。一个清晰的接口，比十行注释更能说清“这里该干什么”。
