面向接口编程的核心是替换自由，通过依赖注入解耦调用方与实现，避免硬编码new具体类；接口应只定义行为契约，不暴露实现细节；灵活的关键在于配置驱动和合理拆分接口。
因为面向接口编程让调用方不绑定具体实现，换实现时业务代码一行不用改——灵活性就体现在“替换自由”上。
为什么 new AliyunSmsSender() 会锁死你的代码
写 new AliyunSmsSender() 看似直白，实则把订单服务和阿里云 SDK 深度耦合。一旦要切到腾讯云、加灰度开关、或测试时禁发短信，你就得：
- 全局搜索
AliyunSmsSender，逐个替换构造逻辑 - 改完还得检查所有
try-catch是否适配新异常类型 - 上线前夜改核心类，连带影响日志埋点、监控指标口径
而用接口声明：SmsSender sender，再通过构造器注入，谁创建、怎么初始化、用哪个实现——全交给 Spring 或测试框架管，业务类只管 sender.send(...)。
接口不是摆设：它定义的是“能做什么”，不是“怎么做的”
一个设计不良的 PaymentService 接口如果暴露了 setRetryTimes(int) 或 useMockMode()，就等于强迫所有实现类（微信、支付宝、银联）都支持这些配置细节，违背了接口作为「行为契约」的本质。
立即学习“Java免费学习笔记（深入）”；
正确做法是：
- 接口只保留业务动作：如
process(PaymentRequest)、refund(RefundRequest) - 重试策略、Mock 开关等，应由实现类内部封装，或通过配置中心/环境变量驱动
- 必要时用策略模式+工厂方法组合，而不是把策略参数塞进接口
运行时切换靠多态，但前提是你没在代码里写死类型
接口变量能指向任意实现类对象，靠的是 JVM 的动态绑定机制。但这个能力会被下面这些写法直接废掉：
- 用
instanceof判断实现类类型再分支处理 → 违反开闭原则 - 把
AliyunSmsSender当参数类型传入方法 → 调用方又和实现强绑定了 - 在 service 层 new 实现类，再转成接口类型 → 绕了一圈又回到原点
真正起效的写法是让依赖从外部来：
public class OrderService {
private final SmsSender sender;
// 构造器注入，类型是接口
public OrderService(SmsSender sender) {
this.sender = sender;
}
}
Spring 启动时根据 @Qualifier("tencentSmsSender") 或 profile 自动装配，你只写一次接口调用。
灵活的终点不是接口本身，而是配置驱动+组合能力
光有接口还不够。真正的灵活，是能把「换实现」这件事从代码层移到配置层：
- 用
@ConditionalOnProperty(name = "sms.provider", havingValue = "mock")控制 Bean 加载 - 把实现类名存在
application.yml里，启动时反射加载，避免硬编码 - 用事件代替直接调用：订单创建后发
OrderCreatedEvent，短信服务监听，互不持有对方引用
最容易被忽略的一点：接口不该大而全。一个 UserOperation 接口如果包含注册、登录、改密、冻结、导出……那所有实现类都得填满这堆方法，哪怕只用其中两个。该拆就拆，比如 UserAuth 和 UserAdmin 分开定义，实现类按需实现。
