Java多态是实现开闭原则最直接可靠的技术支点，通过接口定义统一入口、运行时绑定具体实现、避免new硬编码、优先使用接口而非抽象类，使系统新增功能无需修改原有代码。
Java多态是实现开闭原则（OCP）最直接、最可靠的技术支点。它让系统能在不改动已有代码的前提下，通过新增类来支持新行为——不是靠改老逻辑，而是靠换新对象。
用接口定义统一入口，把变化装进多态里
核心是让调用方只认接口或抽象类，不关心具体是谁在干活。比如支付功能：
- 定义 Payment 接口，只声明
pay(Order order) - 支付宝、微信、货到付款各自写一个实现类，互不影响
- 业务类 OrderService 持有
Payment引用，调用时自动走对应实现 - 加数字货币支付？写个
CryptoPayment类实现接口，其他地方一行代码都不动
运行时绑定才是关键，别让 new 出卖了多态
如果还在业务方法里写 new AlipayPayment()，多态就失效了——耦合死死的，扩展无从谈起。
- 把对象创建交给工厂类：传入类型字符串，返回对应 Payment 实例
- 更推荐 Spring 的
@Autowired或构造注入：配置好 Bean，容器自动装配 - 客户端代码永远只操作抽象类型，具体实现由运行时决定
避免抽象层反被拖累，接口比抽象类更安全
抽象类容易带状态和默认实现，一不小心就让新子类踩进旧逻辑的坑。
立即学习“Java免费学习笔记（深入）”；
- 接口没有字段、没有实现，每个实现类必须从头写清自己职责
- 如果非要用抽象类，只放稳定骨架，可变部分全用
abstract方法留空 - 比如日志模板：
log()是 final 流程，doLog()必须子类重写
一眼识别 OCP 是否被破坏
不用看设计文档，翻代码就能判断：
- 方法里出现
if (type.equals("xxx"))或switch分支新增 case？违反 OCP - 每次加功能都要打开
OrderProcessor.java改process()方法体？违反 OCP - 接口里不断加带业务语义的方法，比如
findVipUsersByRegion()？抽象层已失守
