面向接口编程通过依赖抽象而非具体实现来解耦，如SmsSender接口统一行为契约，调用方不依赖阿里云等具体实现；配合多态、依赖注入、事件驱动、组合模式和配置驱动，实现灵活替换与低风险演进。
因为面向接口编程能让代码更灵活、更易替换、更少修改——核心是让调用方不依赖具体实现，只依赖行为契约。
接口是行为的统一契约
就像USB接口规定了“插进去能通电、能传输数据”，但不管背后连的是U盘、手机还是硬盘。Java接口也一样，它定义“能做什么”，不关心“怎么做”。比如定义一个 SmsSender 接口，只声明 send(String phone, String content) 方法，至于是走阿里云短信、腾讯云，还是测试用的模拟发送，都由实现类决定。
- 调用方（如订单服务）只和 SmsSender 打交道，完全不知道也不需要知道底层是谁在发
- 新增一种发送方式？加个新实现类就行，订单服务代码一行不用改
- 测试时想绕过真实短信？换上 MockSmsSender，注入进去就生效
解耦的关键在于“依赖抽象，而非具体”
如果写成 new AliyunSmsSender()，那订单服务就跟阿里云强绑定了。一旦要切到其他渠道，就得全局搜 AliyunSmsSender，挨个替换构造逻辑——上线前夜改代码，风险高、易出错。
- 正确做法：变量声明用接口类型，对象创建交给外部（比如构造器传入）
SmsSender sender;
public OrderService(SmsSender sender) { this.sender = sender; } - 这样，谁来提供 sender 是外部的事；订单服务只专注自己的业务逻辑
- Spring 的 @Autowired 就是这种思想的自动化：框架帮你把实现类塞进来，你只管用接口
多态支撑运行时灵活切换
接口变量可以指向任意实现类的对象，调用方法时，JVM 在运行时自动找到对应实现——这就是多态。它让“同一份调用代码”，在不同部署环境下执行不同逻辑。
立即学习“Java免费学习笔记（深入）”；
- 开发环境用 MockSmsSender，避免频繁触发真实短信
- 测试环境用 TencentSmsSender，验证集成流程
- 生产环境切到 AliyunSmsSender，无需改业务代码
- 甚至可以按用户等级动态选实现：if (user.isVIP()) use PrioritySmsSender else use DefaultSmsSender
不止于接口：解耦是系统级设计习惯
接口只是起点，真正降低耦合还要配合其他实践：
