多态接口设计是落实开闭原则最自然有效的方式：通过接口定义稳定契约，新增功能只需添加实现类并注册，不修改原有代码；需避免接口频繁变更、方法职责不清、实现类间耦合及硬编码分支。
多态接口设计是落实开闭原则（OCP）最自然、最有效的方式之一。核心在于：用接口定义行为契约，用实现类承载具体逻辑，新增功能只需加新实现类，不碰已有代码。
用接口抽象稳定行为
接口代表“不变的约定”，比如PaymentStrategy、Logger、PriceCalculator——这些名称背后是系统中真正稳定的部分：要支付、要记日志、要算价格。只要接口方法签名不变（参数、返回值、语义），所有依赖它的代码就无需改动。
- 避免在接口里频繁增删方法；若真需扩展，可新增接口（如
AdvancedLogger extends Logger），而非修改原接口 - 接口方法应聚焦职责单一，例如
log(String msg)比logToFile(String msg)更符合OCP——后者把实现细节暴露进契约
运行时通过多态切换实现
调用方只面向接口编程，不关心具体是谁实现的。谁来实例化、何时替换，由工厂、配置或依赖注入容器决定。这使得“换策略”变成配置或构造参数的调整，而非源码修改。
- 业务代码写成：
paymentStrategy.pay(order)，而不是if (type == WECHAT) {...} else if (type == ALIPAY) {...} - Spring 中可通过
@Qualifier或 profile 切换 Bean；纯 Java 可用简单工厂或策略上下文（StrategyContext.get("wechat").pay(...)）
新增功能 = 新增实现类 + 少量注册逻辑
当要支持“数字货币支付”或“跨境满减计算”时，你只需要：
立即学习“Java免费学习笔记（深入）”；
- 写一个新类：
CryptoPayment implements PaymentStrategy或OverseaDiscountCalculator implements PriceCalculator - 在配置/工厂/容器中注册它（例如 Spring 的
@Component，或工厂类里加一行map.put("crypto", new CryptoPayment())） - 原有
PaymentService、OrderProcessor等上层模块完全不动
警惕“伪多态”和过度耦合
看似用了接口和实现，但若设计不当，OCP仍会失效：
- 不要让实现类依赖其他实现类（如
WechatPay里直接 newAlipay），否则扩展时连锁修改 - 避免在接口实现中硬编码业务分支（如
if (country.equals("CN")) {...}），这本质是把变化逻辑塞进固定结构里 - 接口方法不应包含与当前实现强绑定的参数（如
pay(BigDecimal amount, String wechatAppId)），应提取为策略配置或上下文对象
