多态提升扩展性：新增子类无需修改调用方代码，只需实现统一接口，通过工厂或Spring注入即可；避免if-else硬编码、接口污染和散落new，保障开闭原则与可维护性。
新增子类时，调用方代码完全不用改
这是多态对扩展性最直接的帮助：只要新类继承同一父类或实现同一接口，所有用到该抽象类型的地方（比如 OrderService.payment.pay(order)）自动适配，JVM 在运行时绑定到新类的重写方法。不需要动一行已有业务逻辑。
- 典型反例是硬编码
if-else判断类型：if (type.equals("alipay")) { new Alipay().pay(); }—— 每加一种支付方式就得改这里，违反开闭原则 - 正确做法是让调用方只依赖
Payment接口，新增ApplePay类实现它，再通过工厂或 Spring 注入即可 - 注意接口方法签名要稳定：比如
pay(Order order)不该暴露 HTTP 客户端细节，否则升级实现时会倒逼上层修改
老功能升级不影响调用链，只需换实现类
当某个子类需要重构（如微信支付从 v2 升级到 v3），你只需要新建一个 WechatPayV3 类，重写 pay() 和 refund() 方法，然后在配置或工厂里替换掉旧实例——OrderService 里那行 payment.pay(order) 依然有效，连编译都不用过。
- 子类可自由引入新依赖：比如
WechatPayV3用OkHttpClient，而Alipay用HttpClient，上层无感知 - 密钥、证书路径等差异化配置，应通过构造函数或
setXxx()注入，不要塞进接口定义里 - 避免在接口中添加“仅某子类需要”的方法，否则其他实现只能抛
UnsupportedOperationException
工厂 + Spring 管理实例，避免 new 散落各处
直接 new Alipay() 是耦合源头。一旦要加统一日志、熔断、灰度开关，就得满项目搜 new，极易漏改。集中管理才是可持续扩展的前提。
@Service
public class PaymentFactory {
private final Map paymentMap;
public PaymentFactory(List payments) {
this.paymentMap = payments.stream()
.collect(Collectors.toMap(Payment::getType, p -> p));
}
public Payment get(String type) {
return paymentMap.get(type);
}
}
- 新增支付方式，只用加一个
@Component类并实现getType()，Spring 自动注入进paymentMap - 不推荐用配置文件+反射动态加载，除非有强隔离需求（如插件化），否则增加调试和排查成本
- 若某子类需特殊行为（如只有支付宝支持红包抵扣），优先定义策略接口
RedPacketSupport，而非在调用方写instanceof Alipay后强制转型
批量处理和测试友好性，常被忽略但影响长期维护
多态天然支持集合泛型统一操作，比如 List 可混装各种支付实现，遍历时自动调各自逻辑；单元测试也更容易用 Mockito.mock(Payment.class) 替换真实服务，不依赖网络或密钥。
立即学习“Java免费学习笔记（深入）”；
- 遍历
List计算总面积，新增Triangle类后，原有循环代码完全不动 - 测试时若发现
Alipay的退款逻辑有问题，只需单独测它，不会波及WechatPay的用例 - 团队协作时，不同人可并行开发
ApplePay和UnionPay，只要契约（接口）不变，集成风险极低
