多态是Java落实开闭原则最直接方式，关键在于调用方依赖抽象、运行时自动切换行为；通过接口定义契约（如Notifier）、各实现类互不影响，新增功能无需修改原有代码。
多态是 Java 落实开闭原则最直接、最自然的方式。核心不在于“用了继承或接口”，而在于调用方是否只依赖抽象，运行时是否能自动切换行为——新增功能时，老代码一行不改。
用接口定义统一契约，把变化关进多态的笼子
接口只声明能力，不带状态、不写实现，天然适合隔离变化。
- 定义一个 Notifier 接口，只含
send(String content)方法 - 微信、短信、邮件各自实现该接口，互不影响
- 业务类（如 OrderService）只持有 Notifier 类型的引用，调用
send()即可 - 要加站内信？只需新增 InternalNotifier 类实现接口，其他所有代码完全不动
运行时绑定才是多态生效的前提
如果还在方法里写 new SmsNotifier() 或用 if (type == "sms") 判断，多态就只是摆设——扩展时仍得改调用逻辑。
- 对象创建交给工厂类或 Spring 容器，比如传入配置项
"wechat"，返回对应实例 - 客户端代码永远操作接口类型，具体是谁干活，由实际传入的对象决定
- 测试时可轻松注入 Mock 实现，不依赖真实渠道
优先选接口，慎用抽象类
接口更轻量、更安全：没有字段、没有默认实现，每个实现类必须明确表达自己怎么做事。
立即学习“Java免费学习笔记（深入）”；
- 抽象类容易悄悄引入共享状态或默认逻辑，新子类可能被旧行为拖累
- 若真要用抽象类，只放稳定骨架，可变部分全用
abstract方法留空 - 例如日志模板：
log()是final流程，doLog()必须子类重写
一眼识别 OCP 是否被破坏
不用看设计文档，翻代码就能判断：
- 方法里出现
if (type.equals("xxx"))或新增case？违反 OCP - 修改
process()方法体来支持新类型？违反 OCP - 参数里带
PaymentType type，再用分支分发？坏味道 - 正确做法是：由子类各自实现，调用方无感知
