猫咪的室友很多人一提到Java中的多态，第一反应就是背诵“同一操作作用于不同对象，产生不同执行结果”这句话。我做了这些年的Java开发，也在技术面试中问过这个知识点，发现大家对多态的理解大多停留在“会背定义、会用例子”，但只要往底层问深一点，比如动态绑定怎么发生的、虚方法表是什么结构、为什么静态方法不参与多态，很多人就绕不清楚了。今天这篇就把Java多态从概念、原理到实战串起来讲透，顺便把面试里的高频考点和容易踩的坑也一并说清楚。适合准备Java基础面试的人，也适合写了一段时间代码但没系统梳理过这块的开发者。
1. 多态到底解决了什么问题
1.1 从一段没有多态的代码说起
先看一个场景。假设你开发一个支付系统，目前接了支付宝和微信两种支付渠道。没有多态的实现方式是这样的：
java复制public class PaymentService {
public void pay(String channel, double amount) {
if ("alipay".equals(channel)) {
System.out.println("使用支付宝支付：" + amount + "元");
} else if ("wechat".equals(channel)) {
System.out.println("使用微信支付：" + amount + "元");
} else {
throw new IllegalArgumentException("不支持的支付渠道");
}
}
}
这个写法的痛点很明显：每新增一个支付渠道（比如银行卡、云闪付），就不得不修改 pay 方法，加一个 else if 分支。代码越写越长，条件判断越来越多，而且所有渠道的逻辑耦合在同一个方法里，想单独测试某个渠道都费劲。这就是典型的违反开闭原则——对扩展开放、对修改关闭。
如果改成多态的写法，代码会变成什么样？看下面：
java复制public interface Payment {
void pay(double amount);
}
public class Alipay implements Payment {
@Override
public void pay(double amount) {
System.out.println("使用支付宝支付：" + amount + "元");
}
}
public class WechatPay implements Payment {
@Override
public void pay(double amount) {
System.out.println("使用微信支付：" + amount + "元");
}
}
public class PaymentService {
private Payment payment;
public PaymentService(Payment payment) {
this.payment = payment;
}
public void pay(double amount) {
payment.pay(amount);
}
}
调用方只需要面向 Payment 接口编程，不需要关心具体的实现是支付宝还是微信。以后新增渠道，只需要新写一个实现类，完全不改 PaymentService。这就是多态的核心价值：通过抽象，把“做什么”和“怎么做”解耦。
1.2 多态的本质是什么
多态的英文是 Polymorphism，拆开看是 poly（多）+ morph（形态），字面意思就是“多种形态”。在Java里，它的本质是一句话：父类引用（或接口引用）指向子类对象（或实现类对象），在运行时表现出不同的行为。
这里有两个关键词需要重点理解：
- 编译期类型：也叫静态类型，是变量声明时使用的类型。
- 运行期类型：也叫实际类型，是对象真正new出来的类型。
java复制Payment p = new Alipay();
上面这行代码中，p 的编译期类型是 Payment，运行期类型是 Alipay。当调用 p.pay() 时，Java虚拟机在运行时会根据实际类型，去调用 Alipay 类里重写的那个方法，而不是 Payment 接口里什么都没写的方法。这个过程叫动态绑定。
1.3 为什么说多态是面向对象的灵魂
面向对象编程有三大特性：封装、继承、多态。很多教学把多态排在最后，给人的感觉是它是附属品。但实际上，多态才是整个面向对象体系的灵魂。封装解决的是“数据的可见性”，继承解决的是“代码的复用性”，而多态解决的是“行为的扩展性”。
可以这么类比：插座就是多态的最好例子。插座接口是公开协议，不管你接入的是台灯、电风扇还是手机充电器，对于插座来说都是一样的——它只管供电。而每一种电器怎么使用电能转换成光和风，这是各个电器自己的事。如果没有插座协议，你每个电器都要自己拉一根电线自己发电，那是灾难。
1.4 多态的运行机制逐步拆解
还是拿支付场景举例。当代码执行到 payment.pay(amount) 这行时，JVM会经历这样一个过程：
- 从本地变量表中取出
payment这个引用，它其实是一个指向堆内存中Alipay对象的地址。 - 通过这个地址找到
Alipay对象在堆内存中的数据。 - 对象的对象头里有一个指针，指向
Alipay类的方法元信息（Klass）。 - 从类元信息中找到
pay方法的方法入口地址，执行它。
这个“调用时才知道该执行哪个方法”的过程，就叫运行时绑定或者动态绑定。对应的是 invokevirtual 指令。与之相对的是静态绑定，比如直接调用一个 static 方法或者 private 方法，JVM在编译期就知道该方法属于哪个类，直接执行。
需要模型API调用？ 免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。
2. 多态的几种实现形式
2.1 方法重写是核心
运行时多态最典型的表现就是方法重写（Override）。子类继承父类后，对父类的方法重新实现，方法名、参数列表、返回类型都要保持兼容，然后在方法上加 @Override 注解（不加也能编译，但加上可以帮你检查是否真的重写成功了）。
java复制public class Animal {
public void speak() {
System.out.println("动物发出声音");
}
}
public class Dog extends Animal {
@Override
public void speak() {
System.out.println("汪！");
}
}
public class Cat extends Animal {
@Override
public void speak() {
System.out.println("喵！");
}
}
当 Animal a = new Dog(); a.speak(); 时，输出的是“汪”。这就是重写带来的多态效果。
2.2 接口实现提供了更强的扩展性
接口实现是另一种多态，也是现代Java项目里最重要的一种。和继承相比，接口有几点优势：
- 一个类只能继承一个父类，但可以实现多个接口。想用多态又不想被继承体系绑死，就选接口。
- 接口定义的是契约，不关心实现。代码里只需要依赖接口，可以随时替换实现，这就是依赖倒置原则的落地。
策略模式、工厂模式、模板方法模式，这些设计模式的核心基础就是接口多态。举个实际例子，一个数据分析系统要支持从MySQL、Redis、Kafka三个地方读取数据。你定义一个 DataLoader 接口，然后三个类分别实现这个接口，上层代码只依赖接口，想切换数据源时只需要换传参的对象。
2.3 方法重载是不是多态
严格来说，方法重载（Overload）属于编译期多态，也叫静态多态。它是在编译期就确定了要调用哪个方法，依据是方法的参数个数、参数类型。比如：
java复制public class Calculator {
public int add(int a, int b) {
return a + b;
}
public double add(double a, double b) {
return a + b;
}
}
调用 add(1, 2) 时，编译器根据实参类型匹配第一个方法；调用 add(1.0, 2.0) 时，匹配第二个方法。这个过程在编译阶段就完成了，跟运行期的动态绑定不是一回事。
但在实际开发中，面试官问“多态有哪些形式”，你把重载也算一种多态是没问题的，只需要解释清楚它是编译期多态，和重写的运行时多态不一样。
2.4 泛型中的多态思想
Java泛型里的 List<String> 和 List<Integer>，虽然是同一个 List 接口，但处理的数据类型不同。泛型的设计目标之一，就是让你写出“可以用来处理多种类型”的代码，本质上也是一种多态思维。不过泛型在Java里是通过类型擦除实现的，运行期并不真的存在 List<String> 这个类，和传统多态的实现方式差别很大。
3. 多态的底层原理
3.1 四种方法调用指令
在JVM的字节码层面，方法调用指令一共有四条，理解它们能帮你透彻理解多态：
invokestatic：调用静态方法，编译期确定，静态绑定。invokespecial：调用private方法、构造方法、super方法，编译期确定，静态绑定。invokevirtual：调用非私有实例方法，运行期确定，动态绑定。invokeinterface：通过接口引用调用方法，运行期确定，动态绑定。
重写的多态效果，靠的是 invokevirtual 和 invokeinterface 这两条指令实现。
3.2 虚方法表如何工作
Java的类在加载到JVM之后，会在方法区（元空间）中为每个类生成一份方法元信息。对于包含或继承虚方法的类，JVM会维护一张虚方法表（vtable）。这张表是一个数组，每一项指向某个方法的实际入口。
当一个对象调用一个虚方法时，JVM先根据对象的实际类型，从对应该类型的虚方法表中找到方法的入口地址，然后执行。如果子类重写了这个方法，虚方法表中存的就是子类方法的入口；如果没重写，存的就是父类方法入口。
用前面的 Animal 例子来说明，Animal 类的虚方法表里，speak() 指向 Animal.speak() 的入口；Dog 类的虚方法表里，speak() 指向 Dog.speak() 的入口。所以 Animal a = new Dog() 之后调用 a.speak()，JVM根据 a 指向的 Dog 对象，从 Dog 的虚方法表里找到了 Dog.speak()，执行的是子类的方法。
提示：虚方法表的引入，让方法调用从“每次都去类里搜一遍”变成了“查表”，查找时间由混乱搜索变成了常数时间，这是HotSpot虚拟机提高多态调用性能的关键手段。
3.3 多态调用有没有性能损耗
早期大家普遍认为动态绑定比静态绑定慢很多，因为要多一次查表。但实际上，现代JVM里的JIT编译器对这种场景做了大量优化，最著名的就是内联缓存（Inline Cache）。它会在方法调用点记录上一次命中的类型，如果下一次调用还是同样的类型，就直接命中缓存，连查表都省了。
在绝大多数业务代码里，多态带来的性能损耗完全可以忽略。真正需要关心性能的，是超高并发、超高频调用的底层框架代码。即使是这种场景，也还有很多优化手段可以先做的。我的建议是：不要因为那点性能损耗而放弃用多态做设计，收益远大于成本。
4. 向上转型与向下转型
4.1 向上转型是安全的
向上转型（Upcasting）就是子类对象赋给父类引用。这种转换是自动的、隐式的，也是安全的，因为子类一定“是一个”父类。
java复制Dog dog = new Dog();
Animal animal = dog; // 向上转型，自动完成
转型之后，animal 引用只能调用父类中定义的方法，访问不了子类独有的方法。也就是说，向上转型实际上“缩小”了你对对象的操作能力，但反过来提高了代码的通用性。
这也是多态之所以成立的前提：所有子类对象都能当作父类类型来用，你才能写一个处理父类类型的方法，给它传不同的子类对象来完成不同的行为。
4.2 向下转型必须注意安全
向下转型（Downcasting）是父类引用转回子类引用，方向相反，需要显式强制类型转换。
java复制Animal animal = new Dog();
Dog dog = (Dog) animal; // 向下转型，需要强转
问题是，如果 animal 实际指向的不是 Dog 类，强转就会抛 ClassCastException。你可能会想：那我用 instanceof 检查一下不就行了。
java复制if (animal instanceof Dog) {
Dog dog = (Dog) animal;
}
这里有个容易踩的坑：instanceof 判断为 true，不代表强转一定安全。比如 animal 指向的是一个 Dog 对象，但这是 Dog 的某个子类呢？强转成 Dog 是安全的，因为子类依然是 Dog。但如果你用 instanceof 判断的是 animal instanceof Dog，而 animal 实际指向的是 Cat，那么判断为 false，不会执行强转，也是安全的。所以 instanceof 配合向下转型，在绝大多数场景下是可靠的。
4.3 一个容易忽略的细节：getClass() 与 instanceof 的区别
instanceof 会考虑继承关系，而 getClass() 比较的是运行时的具体类。这两种判断方式适用于不同场景。
java复制Animal animal = new Dog();
// true，因为 Dog 是 Animal 的子类
System.out.println(animal instanceof Animal);
// true，运行时类型确实是 Dog
System.out.println(animal.getClass() == Dog.class);
// false，运行时类型是 Dog，不是 Animal
System.out.println(animal.getClass() == Animal.class);
如果你要做精确类型判断，用 getClass() 比较；如果你要做“是某个类或它的子类”的判断，用 instanceof。比如在一次需要严格区分 Dog 和 Dog 的子类 GuideDog 的场景里，instanceof 会把两者都判为 true，而 getClass() 能精确区分出确实是 Dog 这个类。
5. 重写与重载的界线
5.1 重写需要遵守哪些规则
方法重写不是随便想怎么写就怎么写的，它有严格的约束：
- 方法名、参数列表必须完全一致，否则是重载不是重写（前提是发生在同一个类，或者是子类新增了一个方法）。
- 返回类型可以不相同，但必须是原返回类型的子类型，这叫协变返回类型。
- 访问权限不能比父类更严格，父类是
protected的，子类重写时只能是public或protected，不能变成private。 - 抛出的受检异常不能比父类更宽，可以少抛或不抛，但不能抛出父类方法没有声明且更宽泛的受检异常。
为什么访问权限不能变严？因为多态成立的前提之一是“子类能替换父类”。如果父类的方法对调用方公开，子类重写后突然变成 private 了，那所有通过父类引用调用这个方法的场景都会崩掉，替换原则就被破坏了。
5.2 重载的判断规则与常见误区
重载看的是方法名相同、参数列表不同。参数列表不同包含三种情况：
- 参数个数不同。
- 参数类型不同。
- 参数顺序不同（虽然不建议这么干，但语法上合法）。
这里有三个非常容易搞混的细节：
第一，返回值不同不构成重载。 如果两个方法名字相同、参数列表相同，只是返回类型不同，这无法通过编译。原因很简单：你在调用的时候可以不接收返回值，method() 这样调，编译器不知道你想调哪个版本。
第二，重载方法的选择在编译期就决定了。 就算对象的运行期类型是子类，但如果编译期类型是父类，调用时会按父类的方法匹配重载版本。
java复制public class Parent {
public void show(String s) {
System.out.println("Parent String");
}
}
public class Child extends Parent {
public void show(Object o) {
System.out.println("Child Object");
}
}
Parent p = new Child();
p.show("hello");
猜猜输出什么？输出的是 Parent String，而不是 Child Object，因为重载是编译期静态绑定，p 的编译期类型是 Parent，编译器从 Parent 类中找匹配的方法，找到 show(String) 就绑定了。
第三，父类调用子类重写的方法可能造成困惑。 这是面试里最常见的变体题，我会在下一节详细展开。
5.3 重写与重载的区别对照表
| 对比维度 | 方法重写（Override） | 方法重载（Overload） |
|---|---|---|
| 发生位置 | 父类和子类之间 | 同一个类内部 |
| 方法名 | 相同 | 相同 |
| 参数列表 | 必须相同 | 必须不同 |
| 返回类型 | 可以是原返回类型的子类型 | 可以不同 |
| 访问权限 | 不能比父类更严格 | 无限制 |
| 绑定方式 | 运行期动态绑定 | 编译期静态绑定 |
| 关键字 | 用 @Override 标注 |
无固定标注 |
6. 多态实战中那些反直觉的坑
6.1 属性不存在多态，只有隐藏
很多人以为多态适用于所有成员，实际上成员变量不参与多态。看这个经典例子：
java复制public class Parent {
public String name = "parent";
public void print() {
System.out.println(name);
}
}
public class Child extends Parent {
public String name = "child";
@Override
public void print() {
System.out.println(name);
}
}
Parent p = new Child();
System.out.println(p.name); // 输出 parent
p.print(); // 输出 child
同样的对象，p.name 输出的是 parent，而 print() 方法里输出的却是 child。原因在于，Java的属性访问是静态绑定的，变量 p 的编译期类型是 Parent，所以 p.name 访问的是 Parent.name。而 print() 是虚方法，动态绑定到了 Child.print()，方法内部的 name 就近访问的是 Child 类的 name。
这个知识点经常被用来出题，也非常容易蒙对一半错一半。实际写代码时，规范要求是：父类属性全部声明为 private，通过 getter/setter 访问，子类不要重新定义一个同名字段，否则不仅没有多态效果，还会埋下诡异的Bug。
6.2 静态方法不参与多态
静态方法是属于类的，不属于某个具体对象，所以不会表现出多态行为。
java复制public class Parent {
public static void hello() {
System.out.println("Parent hello");
}
}
public class Child extends Parent {
public static void hello() {
System.out.println("Child hello");
}
}
Parent p = new Child();
p.hello(); // 输出 Parent hello
这里 p.hello() 看起来很像是调用子类的方法，实际上编译器会根据 p 的编译期类型（Parent）直接绑定到 Parent.hello()，和运行期对象完全无关。在代码规范里，强烈建议通过类名调用静态方法，而不是通过对象调用，就是为了避免这种误导。
6.3 private 方法不参与多态
private 方法对子类不可见，因此子类根本无法重写它。如果子类写了一个和父类 private 方法同名同参数的方法，那只是子类新增的一个方法，与重写无关。
java复制public class Parent {
private void secret() {
System.out.println("Parent secret");
}
}
public class Child extends Parent {
private void secret() {
System.out.println("Child secret");
}
}
Parent p = new Child();
p.secret(); // 编译都过不了，private 方法外部不可见
如果在类内部调用自己的 private 方法，那走的是 invokespecial 指令，静态绑定，与多态无关。
6.4 构造方法中的动态绑定陷阱
这是一个特别隐蔽的坑。在父类的构造方法里调用一个虚方法，如果子类重写了这个虚方法，那么创建子类对象时，父类构造方法里调用的实际上是子类重写后的方法。而这时子类还没初始化完成，字段可能还是默认值，很容易出现意想不到的结果。
java复制public class Parent {
public Parent() {
init();
}
public void init() {
System.out.println("Parent init");
}
}
public class Child extends Parent {
private String name = "child";
public Child() {
// 隐式调用 super()，会触发父类构造方法
}
@Override
public void init() {
System.out.println("Child init, name=" + name);
}
}
new Child(); // 输出：Child init, name=null
看到 name=null 了吗？因为在执行父类构造方法时，子类的字段还没有被赋值，Java的默认初始化流程是：
- 分配内存，所有实例变量设为默认值（引用类型为 null、数值为 0）。
- 调用
super()，执行父类构造方法。 - 子类字段初始化语句执行
name = "child"。 - 执行子类构造器剩余代码。
所以在第2步调用父类构造方法时，子类字段只是默认值，被重写的 init() 方法读到的自然是 null。
在Spring等框架的初始化流程里，如果你在基类的构造方法中调用了某个可被重写的方法，很容易因为子类状态还没准备好而出现问题。推荐的做法是：不要在构造函数里调用虚方法。把初始化逻辑放到显式的 init() 方法中，由子类自己控制时机。
6.5 instanceof 与强转的配合问题
向下转型最怕 ClassCastException，所以很多同学会习惯性地写 if (obj instanceof Dog) 然后强制转换。这个做法本身没问题，但要关注一个边界：如果 obj 为 null，instanceof 返回的是 false，不会抛异常，这在某些场景下反而会掩盖问题。
java复制if (null instanceof Dog) { // 输出 false，不抛异常
// 不会进入
}
如果你 if (obj instanceof Dog) 判断之后，在分支里把 obj 当成 Dog 用，基本是安全的。但如果你判断的类和强转的目标类不一致，比如 if (animal instanceof Animal) 然后强转成 Dog，编译器不会报错，运行期可能就炸了。保持判断类和强转类型一致，是基本素养。
7. 高频面试题与设计模式中的多态
7.1 三个经典面试输出题
面试官最喜欢用“代码输出”来考察多态理解程度。下面这三个题目几乎覆盖了所有考点。
题目一：向下转型与重写
java复制class A {
public void show() {
System.out.println("A");
}
}
class B extends A {
public void show() {
System.out.println("B");
}
}
public class Main {
public static void main(String[] args) {
A a = new B();
a.show();
}
}
输出：B。没什么悬念，动态绑定，调用运行期类型 B 的方法。
题目二：重载与重写混合
java复制class A {
public void show(A a) {
System.out.println("A.show(A)");
}
public void show(B b) {
System.out.println("A.show(B)");
}
}
class B extends A {
public void show(A a) {
System.out.println("B.show(A)");
}
}
public class Main {
public static void main(String[] args) {
A a = new B();
B b = new B();
a.show(b);
}
}
输出是 B.show(A)。分析一下：a 的编译期类型是 A，运行期类型是 B。调用 a.show(b) 时，编译器看到 a 是 A 类型，b 是 B 类型，优先匹配 A 类中的 show(B) 方法，编译期绑定到 A.show(B)。但运行期动态绑定，A.show(B) 被子类重写了吗？没有，B 类只重写了 show(A)，没有重写 show(B)，所以运行期应该执行 A.show(B)。但为什么结果是 B.show(A)？
再仔细想，编译器虽然优先匹配 show(B)，但这个方法是 A 类自己的方法，不是虚方法覆盖，所以动态绑定时还是可以执行。然而在实际编译中，可能匹配到了 B.show(A)，因为 b 的运行期类型也是 B，在 B 类中有更具体的重载匹配。
这种题非常容易绕晕。其实解题关键是：编译期看声明类型匹配重载，运行期看实际类型绑定重写。 编译器根据 a 的声明类型 A 和 b 的声明类型 B，找到 A.show(B) 这个候选方法；而 A.show(B) 没有被子类重写，所以运行期执行的就是 A.show(B)，输出应为 A.show(B)。如果你真的在自己环境里跑，发现是 A.show(B) 而不是 B.show(A)，那说明官方规范和我的分析一致。
提示：如果你遇到的第三方资料或者网上答案和这里不一致，建议以官方编译运行结果为准。这种“奇葩重载+重写”的题目，与其死记，不如掌握原理，然后亲手写代码验证。
题目三：属性隐藏
java复制class A {
int x = 1;
}
class B extends A {
int x = 2;
}
public class Main {
public static void main(String[] args) {
A a = new B();
System.out.println(a.x);
}
}
输出：1。属性不参与多态，编译期类型 A，访问 A.x 的值。
7.2 设计模式中的多态运用
多态不是测试题里的玩具，它是很多设计模式的基石。
策略模式：我们前面说的支付案例其实就是策略模式。定义一个策略接口，多个实现类表示不同策略，运行时可替换。
工厂模式：工厂方法返回的是接口类型或抽象类类型，具体的对象是哪个子类，由工厂决定。调用方拿到的只是接口引用，并不知道具体实现类。
模板方法模式：父类定义算法骨架，其中的某些步骤由子类重写实现。父类的模板方法通常是 final 的，防止被子类重写，而细节步骤则利用多态让不同子类提供不同实现。
如果你的设计里大量使用 if-else 分支来根据类型做不同处理，优先级最高的重构方向就是思考能不能用多态消灭这些分支。这不是为了炫技，而是让代码更好维护、更好测试、更容易扩展。
8. 多态在实战编码中的规范建议
8.1 什么时候用多态判断依据
我通常用三个问题来判断一个场景是否该用多态：
- 这段代码是否存在“根据不同类型做不同处理”的
if-else或switch？ - 这些类型是否共享同一个行为？
- 未来是否可能增加新的类型？
三个问题如果两个以上是肯定的，你就应该考虑引入接口或抽象类加多态了。
但也要提醒一下，多态不是万能的。如果一个行为的实现只和类型有关，且类型数量极少、几乎不会增加，直接写条件判断也没问题。过度设计同样是罪过，简单性永远优先。
8.2 面向接口编程是最好的多态实践
所谓面向接口编程，就是让变量的声明类型尽量用接口或抽象类，而不是具体实现类。这样做的好处有三个：
- 替换性：换一个实现类时，不需要改调用代码。
- 可测试性：可以轻松地用Mock对象替换真实实现，做单元测试。
- 隔离性：调用方只依赖接口，不依赖具体实现细节，实现方想怎么改都行。
我在实际项目里见过不少开发者在变量声明的类型上随手写一个 ArrayList 而不是 List，然后后面所有代码都依赖 ArrayList 特有的方法（比如 ensureCapacity）。虽然短期没问题，但一旦想换成 LinkedList，改动成本就高了。能用接口类型声明的地方，养成习惯用接口。
8.3 一个完整的多态重构范例
最后给你一个从重构到落地的完整小例子，帮助你建立“用多态改代码”的直观感觉。
原始代码：
java复制public double calcPrice(String type, double amount) {
if ("normal".equals(type)) {
return amount;
} else if ("vip".equals(type)) {
return amount * 0.8;
} else if ("student".equals(type)) {
return amount * 0.5;
} else {
return amount;
}
}
重构后用多态：
java复制public interface PricingStrategy {
double calc(double amount);
}
public class NormalPricing implements PricingStrategy {
@Override
public double calc(double amount) {
return amount;
}
}
public class VipPricing implements PricingStrategy {
@Override
public double calc(double amount) {
return amount * 0.8;
}
}
public class StudentPricing implements PricingStrategy {
@Override
public double calc(double amount) {
return amount * 0.5;
}
}
public class PriceCalculator {
private final PricingStrategy strategy;
public PriceCalculator(PricingStrategy strategy) {
this.strategy = strategy;
}
public double calc(double amount) {
return strategy.calc(amount);
}
}
以后要加一个“满减策略”，只管写新的实现类，PriceCalculator 一行不用改。调用方只需要决定传入哪个策略对象。
我在实际项目里做过类似的改造，感受最深的一点是：重构完之后，那些原本塞满了分支的判断逻辑消失之后，方法的圈复杂度直线下降，单元测试写起来也舒坦多了——每个策略类单独测，边界情况清清楚楚，不再需要构造各种参数组合去覆盖所有分支。
Java多态这个东西，概念说出来每个人都能接两句，但真正把它用好，靠的是对动态绑定、方法重写规则、编译期与运行期类型这些底层细节的扎实理解。面试问到你的时候，能顺手画一下虚方法表的结构，再举一个项目里用多态消灭条件分支的例子，基本就能和只背定义的人拉开差距了。最后再分享一个小技巧：遇到拿不准的多态输出题，别猜，直接写个小Demo跑一下，结合字节码看看用了哪个指令，比背十道面试题都管用。