多态是java落实开闭原则最自然有效的手段，核心在于用接口隔离变化、运行时绑定实现、新增功能仅加类不改旧码。
多态是 Java 落实开闭原则最自然、最有效的手段——新增功能靠加类，不改老代码。关键不在“用了多态”，而在于是否真正把变化关进抽象的笼子，让运行时自动选择行为。
用接口定义稳定契约，把变与不变分开
接口只声明能力，不带状态、不写实现，天生适合隔离变化。比如定义一个通知行为：
-
Notifier 接口：只含
send(String content)方法 - 微信、短信、邮件类各自实现该接口，彼此完全独立
-
业务类（如 OrderService）只持有
Notifier类型引用，调用send()即可
要加站内信？只需新增 InternalNotifier 类实现接口，其他所有代码一行不动。
Javascript Sdk
下载
用于 inference.sh 的 JavaScript/TypeScript SDK，可运行 AI 应用、构建代理、集成 150+ 模型。包名：@inferencesh/sdk（npm install），完整 TypeScript 支持。
运行时绑定才是多态生效的前提
如果还在方法里写 new SmsNotifier() 或用 if (type == "sms") 判断，多态就只是摆设——扩展时仍得改调用逻辑。
- 对象创建交给工厂类或 Spring 容器，比如传入配置项
"wechat"，返回对应实例 - 客户端代码永远操作接口类型，具体是谁干活，由实际传入的对象决定
- 测试时可轻松注入 Mock 实现，不依赖真实渠道
优先选接口，慎用抽象类
接口更轻量、更安全：没有字段、没有默认实现，每个实现类必须明确表达自己怎么做事。
- 抽象类容易悄悄引入共享状态或默认逻辑，新子类可能被旧行为拖累
- 若真要用抽象类，只放稳定骨架，可变部分全用
abstract方法留空 - 例如日志模板：
log()是final流程，doLog()必须子类重写
一眼识别 OCP 是否被破坏
不用看设计文档，翻代码就能判断：
- 新增功能后，是否要在原有
switch/case或if-else中加分支？→ 违反 OCP - 调用方是否需要显式
new具体子类，或硬编码类型名？→ 抽象没立住 - 接口是否随每个新需求不断添加方法，导致旧实现类被迫抛
UnsupportedOperationException？→ 契约不稳定 - 是否在父类里加 flag 字段和条件逻辑来兼容新行为？→ 把变化点暴露到稳定层
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
