解耦接口与实现类的关键在于切断编译期依赖、延迟绑定时机、隔离变化点，具体通过工厂模式隐藏创建细节、策略模式运行时切换行为、桥接模式分离正交维度、适配器模式对接异构接口。
解耦接口与实现类，关键不是“怎么写接口”，而是“怎么让调用方彻底不知道实现是谁”。核心在于切断编译期依赖、延迟绑定时机、并把变化点隔离到可控范围内。下面从四个实战角度讲清楚怎么做。
用工厂模式隐藏 new 的细节
直接 new 实现类是耦合的起点。工厂模式把创建逻辑收拢，调用方只面向接口获取实例。
- 定义统一接口，比如 NotificationService，含 send(String content) 方法
- 写多个实现类：EmailService、SmsService、WechatService
- 建一个 NotificationFactory 类，提供静态方法 create(String type)，内部用 if 或 Map 分发
- 业务代码只写 NotificationService ns = NotificationFactory.create("sms"); ns.send("订单已支付")
新增推送渠道？加个 PushService 实现 + 修改工厂分支即可，业务层完全不动。
靠策略模式按需切换行为
当不同场景需要不同实现逻辑（比如折扣计算、支付方式、路由规则），策略模式让接口和实现的绑定发生在运行时。
- 定义 PricingStrategy 接口，含 calculate(double amount) 方法
- 实现 VipDiscountStrategy、SeasonalDiscountStrategy 等
- 业务类持有一个 Strategy 引用，在构造或方法参数中传入，不硬编码具体类型
- 调用方决定传哪个策略，比如 new OrderProcessor(new VipDiscountStrategy())
策略可配置化（如从配置中心读取类名），甚至支持运行时热替换，彻底解除实现类对业务流程的侵入。
借桥接模式拆开抽象与实现维度
当系统存在多个正交变化方向（比如消息类型 × 消息渠道 × 加密方式），继承会导致类爆炸；桥接模式用组合替代继承，让两边独立演进。
- 定义 MessageSender（抽象层）和 DeliveryChannel（实现层）两个接口
- MessageSender 持有 DeliveryChannel 引用，所有发送逻辑委托给它
- 新增一种消息类型（如 AlertMessage）只需扩展抽象层；新增一种渠道（如 DingTalkChannel）只需扩展实现层
- 两者组合使用，无需为每种组合写新类
这种结构天然适合插件化设计，比如日志框架里 Appender（实现）和 Logger（抽象）就是典型桥接。
以适配器模式对接已有接口
第三方 SDK 或遗留系统常提供不匹配的接口。与其改对方或自己重写，不如加一层适配器，让旧实现“穿上新接口的外衣”。
- 假设老系统有个 LegacyPayment 类，方法是 process(long orderId, String currency)
- 而你统一对接的接口是 PaymentGateway，方法是 charge(PaymentRequest req)
- 写一个 LegacyPaymentAdapter 类，implements PaymentGateway，内部包装 LegacyPayment 实例
- 业务层只依赖 PaymentGateway，后续替换成新支付系统时，只要换掉适配器，其他代码照常运行
适配器不改变原有逻辑，只做协议转换，是安全接入外部系统的标准做法。
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
