开闭原则即“对扩展开放，对修改关闭”，多态是其核心实现方式；通过定义接口、各实现类独立封装、运行时动态绑定，新增功能只需添加类而不修改原有代码。
开闭原则说白了就是：加新功能，不改老代码。多态是它最常用、最自然的落地方式。
多态让调用方只依赖接口，不碰具体实现
比如支付系统有微信、支付宝、银行卡三种方式。如果不用多态，你可能写一堆 if-else 判断渠道再调对应方法；一旦新增 Apple Pay，就得打开原有支付类，往里加新判断和调用逻辑——这明显违反“对修改关闭”。
换成多态后，定义一个 PayService 接口，三个渠道各自实现它。业务代码只面向接口编程：
- 调用方只声明 PayService service，不关心它是哪个子类
- 新增 ApplePayService 只需实现接口，注册进工厂或 Spring 容器
- 原有支付流程（如订单服务）完全不动，连编译都不需要重新触发
运行时动态绑定，行为变化由对象类型决定
父类引用指向不同子类对象，同一句 service.pay(order) 在运行时自动调用对应实现。这种“相同调用，不同结果”的能力，正是“对扩展开放”的体现——扩展新行为，靠的是新增类，而不是修改已有方法体。
关键不在语法上用了 extends 或 implements，而在于：变化点被封装进独立类中，且调用链不依赖其实现细节。
配合策略+工厂，把“选哪个实现”也解耦出来
单纯多态还不够稳健。实际项目中，通常搭配策略模式（按业务规则选实现）和简单工厂（按参数返回对应实例）：
- 策略类根据 channel 字段选择 PayService 实现，但策略本身不 new 具体类，而是从容器或工厂拿
- 工厂新增一个 else if 分支支持 ApplePay，其余逻辑照旧；更优做法是用配置驱动，连工厂都免改
- 这样，从接口定义 → 实现类 → 策略路由 → 调用入口，整条链路都满足“改一处、扩一类、不动其他”
注意别掉进“伪多态”陷阱
有些代码看似用了继承或接口，但依然在方法里写 if-else 判断类型再转型调用，或者把所有逻辑塞进一个上帝类里用 instanceof 区分行为——这本质还是条件驱动，不是真正多态。
判断是否真符合开闭原则，就看：新增一种情况，是否只需要新增一个类 + 少量配置，而所有已有 .java 文件都不动？如果答案是否定的，那只是披着多态外衣的硬编码。
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
