面向接口编程的核心是调用方只关注“能做什么”而非“怎么做”，通过契约隔离变化，使系统更易扩展、测试和维护。

面向接口编程不是为了炫技，而是让系统在需求变化时少改几行代码、少踩几个坑。核心就一点：调用方只认“它能做什么”，不关心“它怎么做”。一旦把具体类名写死在业务逻辑里，后续替换实现、加新功能、写单元测试，全都会变得吃力。

接口是契约，实现是方案

接口定义行为边界，比如一个PaymentProcessor接口只声明process(amount)和refund()两个方法；而微信支付、支付宝、银行卡支付各自是不同实现。只要它们都遵守这个契约，上层订单服务就无需修改——换支付渠道只是改一行注入配置的事。

常见误区是把接口当成“每个类配一个空壳”。真正该抽接口的，是那些：
• 被多个模块调用的行为（如日志记录、通知发送）
• 明确存在替代方案的环节（如缓存可用Redis或Caffeine）
• 未来可能对接第三方或模拟环境的点（如短信网关、文件存储）

面向实现写法埋下的雷

直接 new 具体类、用 instanceof 判断类型、在 if-else 里硬编码类名，这类写法短期快，长期难维护：

• 新增一种支付方式？得改订单主流程的判断分支，还可能漏掉某处回调处理
• 想给支付加统一埋点或重试逻辑？得挨个修改每个实现类，或在调用处重复写模板代码
• 单元测试只能走真实支付通道？没法快速验证订单状态流转是否正确

怎么落地才不算过度设计

不是所有类都要套接口。判断依据很实在：

• 当前已有两种及以上不同实现，或明确知道三个月内会加第二种
• 该模块会被其他团队复用，或要开放给插件机制（比如报表导出支持Excel/PDF/CSV）
• 不抽接口会导致测试必须依赖外部系统（数据库、HTTP服务），拖慢CI流水线

如果只是一个内部工具类，只被一处调用，且逻辑稳定无扩展预期，直接写实现反而更清晰。

架构层面的收益不止于代码

当核心流程依赖接口而非实现，系统自然形成清晰的分层：

• 上层业务模块只依赖抽象，可以独立编译、单独部署
• 底层实现可按需替换，比如开发环境用内存缓存，生产切Redis，代码零改动
• 新同学看代码先读接口，三分钟明白“这里要完成什么”，不用钻进10个类理清调用链