多态本身不直接实现可扩展性，而是支撑开闭原则的关键机制；真正提供可扩展性的是抽象（interface/abstract class）与具体子类的分离设计，配合工厂或依赖注入解决创建与生命周期问题。
多态本身不是“实现可扩展性”的工具，而是支撑开闭原则（对扩展开放、对修改关闭）的关键机制。真正提供可扩展性的，是配合多态使用的抽象（abstract class 或 interface）+ 具体子类的分离设计。
为什么直接写 if-else 判断类型就破坏可扩展性
常见反模式：if (obj instanceof Dog) { ... } else if (obj instanceof Cat) { ... }。一旦新增 Bird 类，必须修改这段逻辑——违反开闭原则。
这种写法把“行为选择”硬编码在调用处，扩展只能靠改旧代码，无法做到“不碰原有类，只加新类”。
- 每次加新类型都要找到所有类似判断点，漏改一处就出 bug
- 调用方和具体类型强耦合，单元测试难以 mock
- 编译期类型检查失效，
instanceof后强制转型易抛ClassCastException
用 interface + 多态替代类型判断
定义统一契约，让不同实现自己决定行为，调用方只依赖接口。
立即学习“Java免费学习笔记（深入）”；
interface Animal {
void makeSound();
}
class Dog implements Animal {
public void makeSound() { System.out.println("Woof!"); }
}
class Cat implements Animal {
public void makeSound() { System.out.println("Meow!"); }
}
// 扩展只需新增类，无需修改现有代码
class Bird implements Animal {
public void makeSound() { System.out.println("Chirp!"); }
}
// 调用方完全不知道具体类型
public static void feed(Animal a) {
a.makeSound(); // 运行时动态绑定
}
新增 Bird 时：只写新类、只注册（如工厂或 DI 容器），feed() 方法一行不用动。
-
feed()方法签名不变，已编译的调用链不受影响 - IDE 能自动提示所有实现类，便于发现扩展点
- 若用 Spring，
@Component+List注入可自动收集全部实现
抽象类 vs 接口：选哪个更利于扩展
优先用 interface，除非需要共享状态或默认行为逻辑。
- Java 8+ 接口支持
default方法，可提供基础实现（如日志、空校验），但不能有字段 - 抽象类适合有共用字段（如
id、createdAt）或构造逻辑，但一个类只能继承一个抽象类，限制扩展灵活性 - 若未来可能对接第三方库（如 Jackson 序列化、JPA 映射），接口兼容性通常更强
例如：定义 PaymentProcessor 接口比抽象类更合适——微信、支付宝、PayPal 实现互不相关，无需共享字段，且系统可能后期接入更多支付渠道。
容易被忽略的扩展陷阱：构造与生命周期管理
多态只解决“行为调用”问题，但新类型如何创建、何时初始化、是否单例，这些常被忽视，反而成为扩展瓶颈。
- 手写
new Dog()会把具体类名写死，应改用工厂（AnimalFactory.create("dog")）或依赖注入 - 若子类需外部资源（如数据库连接），在构造函数里初始化会导致测试困难；应通过构造参数或
@PostConstruct延迟加载 - Spring 中未加
@Component的新实现类不会被自动扫描，需检查包路径或显式@Import
真正的可扩展性，是连对象创建逻辑都对新增类型透明——否则多态只是半截腿。
