面向接口编程的核心是业务代码只依赖接口而不感知具体实现，通过依赖注入、策略模式和接口拆分实现彻底解耦。
面向接口编程在多实现场景下解耦业务代码，关键不是“怎么写多个实现类”，而是让业务代码彻底不知道、也不需要知道当前用的是哪一个实现。核心是把“选谁”这件事从业务逻辑里拎出去，交给更上层或更外围的机制来决定。
用接口统一行为契约，屏蔽实现差异
业务代码只依赖接口，不 import 任何具体实现类。比如有支付需求：
- 定义 PaymentService 接口，只声明
boolean pay(Order order) - 所有渠道（AlipayService、WechatService、UnionPayService）都实现它
- 业务类（如 OrderService）只持有
private final PaymentService paymentService;，构造时注入
这样，无论后面加第十种支付方式，OrderService 一行代码都不用动。
靠依赖注入容器自动装配，避免手动判断
别在业务方法里写 if ("alipay".equals(type)) new AlipayService() 这类硬编码分支。正确做法是：
立即学习“Java免费学习笔记（深入）”；
- Spring 中用
@Autowired注入接口类型，容器按类型或@Qualifier自动匹配实现 - 需要运行时切换？用
@Primary标记默认实现，或通过@Profile按环境激活不同 Bean - 完全动态？配合工厂类 + Map
预注册，业务层只传 key，工厂返回对应实例
用策略模式把“选哪个”逻辑外移
当选择依据来自配置、用户输入或业务规则时，策略模式最自然：
- 定义 PaymentStrategy 接口，和多个实现类（AlipayStrategy、WechatStrategy）
- 策略上下文类（如 PaymentContext）持有一个
Map<string paymentstrategy></string> - 业务代码调用
context.execute("wechat", order)，内部查表委托，不暴露 if/else - 策略可从配置中心加载类名，甚至支持热替换，业务层零感知
组合优于继承，拆细接口避免大而全
一个接口塞太多方法，会导致所有实现类都被迫承担不相关的职责。例如：
- 错误设计：
MessageService.send() + retry() + log() + getProvider() - 正确拆分：
MessageSender（只发）、RetryPolicy（只重试）、DeliveryLogger（只记日志） - 业务类通过构造器组合三者，各司其职；换短信渠道，只动 Sender 实现，不影响重试逻辑
接口方法数建议 ≤ 3，单个方法参数 ≤ 2，超了就该拆。
