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