如果你已经跟着这个系列学到这儿说明Java基础语法、面向对象、继承和重写这些关都过了。但我猜你现在的状态跟我当年差不多继承好像懂了重写也会写了一提到“多态”总觉得它神神秘秘好像所有框架都在用又好像自己写的练习代码里根本用不上。这篇文章就专门把多态这件事讲透——它的优势是什么、劣势又是什么、什么时候该用什么时候别硬用最后用一个综合练习把这一整块知识串起来。学完这篇你再看别人代码里的抽象类、接口、父类引用就不会再发怵了。1. 多态到底是怎么回事先抛开术语说人话很多教材上来就给定义多态是“同一操作作用于不同的对象可以有不同的解释产生不同的执行结果”。这句话没错但对初学者来说等于没说。我用一个更直白的说法多态就是“用父类的变量调子类的方法”。举个例子假设你有一个父类Animal里面定义了一个方法makeSound()。子类Dog把它重写成打印“汪汪”子类Cat把它重写成打印“喵喵”。如果某段代码里声明了一个Animal类型的变量a这个变量既可以指向Dog对象也可以指向Cat对象。当你调用a.makeSound()的时候程序运行时才会根据a实际指向的对象来决定打印狗叫还是猫叫。其实你没写多态也一样能实现这个效果无非是加一堆if判断if (a instanceof Dog) { ((Dog) a).makeSound(); } else if (a instanceof Cat) { ((Cat) a).makeSound(); }但等你接触Spring、MyBatis这些框架会发现它们底层到处都在用“父类引用 重写方法”这种组合。原因很简单框架不知道你将来要写什么类它只能面向一个抽象层编程。你负责实现具体的子类框架负责在运行时调用。这就是多态的核心价值——把“调用方”和“被调用的具体类型”解耦。1.1 学多态之前你得先确保两件事第一继承关系要清晰。多态的前提是必须有父类/接口和子类没有继承和实现关系多态无从谈起。第二要理解方法重写Override。子类继承父类方法后需要按自己的需求重新实现。这里有一个看起来很基础但非常重要的细节重写要求方法签名完全一致包括方法名、参数列表、返回值类型。一旦签名不一致你以为自己在重写实际变成了重载程序结果就完全不是你想的那样了。另外多说一句多态在Java里主要有两种形态一种是“编译期多态”也就是方法重载同一个类里多个同名方法、不同参数列表编译器在编译时就能确定要调哪个另一种是“运行期多态”也就是我们这篇文章讨论的重点——方法重写配合父类引用编译时编译器只知道调的是哪个方法名但真正执行哪个子类的实现要等程序跑起来才知道。很多初学者把重载和重写搞混考试都能混过去一写代码就露馅。记住一句话重载是“同一个类里的事儿”重写是“父子类之间的事儿”。多态讲的是重写不是重载。1.2 把“变化”交给运行时而不是交给if-else为什么说运行时决定调用哪个方法是件好事因为软件最大的敌人不是写得慢而是需求变来变去。你今天写了if (animal instanceof Dog)明天加一个Bird类就得改原来的代码后天加一个Fish类又得改。每加一个新类型你都要在原来的判断逻辑上动刀改着改着就把别的逻辑改坏了。多态的思路是未来新增的类型都去实现同一个父类方法原有的调用代码一个字符都不用动。程序跑起来遇到新的子类对象自动就调用到了它自己的实现。你从“改代码”变成了“加代码”。这两件事在项目维护里的体验完全不是一个量级。2. 多态的优势为什么一个普通练习也能看出差距光说概念没意思我们写一个实际的场景来对比。假设你在开发一个员工薪资计算功能公司里有三种员工普通员工、经理、实习生。每个人的薪资计算规则不一样。第一种写法不用多态public class SalaryService { public double calculate(Employee e, int type) { if (type 1) { // 普通员工底薪 return e.getBaseSalary(); } else if (type 2) { // 经理底薪 绩效奖金 return e.getBaseSalary() e.getPerformanceBonus(); } else if (type 3) { // 实习生固定津贴 return 3000; } return 0; } }这个代码的问题非常明显type 3这个分支里e这个参数根本没用到实习生就不该是这里的调用者而如果公司新招一种“外包员工”你就得改这个calculate方法再加一个else if。更难受的是将来每个员工的类型都对应一套完整业务逻辑这个方法会越写越长最终变成一个几千行没人敢动的“上帝方法”。用多态重构一下。抽象类public abstract class Employee { private String name; protected double baseSalary; public Employee(String name, double baseSalary) { this.name name; this.baseSalary baseSalary; } public abstract double calculateSalary(); public String getName() { return name; } }三个子类各自重写public class RegularEmployee extends Employee { public RegularEmployee(String name, double baseSalary) { super(name, baseSalary); } Override public double calculateSalary() { return baseSalary; } } public class Manager extends Employee { private double performanceBonus; public Manager(String name, double baseSalary, double performanceBonus) { super(name, baseSalary); this.performanceBonus performanceBonus; } Override public double calculateSalary() { return baseSalary performanceBonus; } } public class Intern extends Employee { public Intern(String name) { super(name, 3000); } Override public double calculateSalary() { return 3000; } }这时原本那个薪资服务类变成public class SalaryService { public double calculate(Employee e) { return e.calculateSalary(); } }你没看错核心逻辑就这一行。以后再增加“外包员工”“兼职员工”只需要新建一个类继承Employee并重写calculateSalary()SalaryService想都不用想。**这是多态最核心的优势对扩展开放对修改关闭。**框架程序员们天天说“开闭原则”落到代码层面其实就是这么一回事。2.1 扩展新功能时旧代码终于不用再动继续用上面这个例子说。一家公司刚开始只有普通员工后来才有经理、实习生。用传统if-else的写法每加一种角色就要改薪资服务类的源码至少要加一个分支。试用期都过去三轮了你还在同一个类里到处加else if代码越来越脆。用多态之后流程变成了这样新员工类型 → 新建一个类 → 继承Employee→ 实现calculateSalary()。原来的类变得极其稳定几乎不需要碰。这在多人协作的项目里特别重要——你不需要理解别人写的几千行逻辑只需要参考现成的子类复制一个结构填自己的代码就行。别人也不需要因为你加了一个新类而重新测试旧的薪资服务。2.2 让不相关的类看起来“同一种样子”多态还有一个很容易被忽略的好处它能抹平类型差异让调用方只关心“这个东西能不能做某件事”而不关心“它具体是什么”。比如你要开发一个系统需要把一堆不同格式的报表导出成PDF。Excel报表、Word报表、图片报表它们的导出逻辑完全不同。如果不用多态你得写一个if (obj instanceof ExcelReport)去挨个判断。用多态以后你只需要定一个接口ReportExporter里面放一个export()方法让三种报表类分别实现。调用方只要遍历这些对象统一调用export()就好。你不需要知道它内部是用了Apache POI还是PDFBox也不需要在调用方引入任何具体类型的判断。这也是为什么Java里那么多框架都爱用“接口 实现类”这套组合拳——调用方只依赖接口具体实现可以随时替换甚至可以由外部配置决定。你写自己的小工具时可能觉得无所谓但一旦代码规模上来“依赖抽象而不是依赖具体”这一个习惯就能帮你省掉无数改代码的时间。2.3 代码复用和一致性维护跟着一起解决了多态让公共逻辑集中在了父类里。比如上面例子中getName()方法、name字段都写在父类Employee里所有子类自动继承。将来如果我们要给所有员工加一个getEmployeeId()方法也只要在父类里加一次就行。更妙的是当你有大量子类对象需要统一处理时多态保证它们的行为都是一致的。比如公司季度大会要遍历所有员工展示个人信息for (Employee e : employeeList) { System.out.println(e.getName() 的薪资是 e.calculateSalary()); }有没有发现employeeList里存的是经理、普通员工、实习生的混合体但你完全不用关心具体是谁。这种代码读起来像在读业务文档遍历所有员工显示姓名计算薪资。干干净净。这才是多态真正“香”的地方——让你的代码从“怎么实现”变成了“要做什么”的层面。3. 多态的劣势与暗坑不是所有地方都适合用网上讲多态的文章大多在吹它的好处很少提它的代价。但实际写代码的时候因为用错多态而吃亏的情况真不少。我不是劝你别用多态而是要你学会识别它不适用的场合。3.1 性能开销动态分派没那么便宜先从争议最少的说起。Java方法调用默认是虚方法调用子类重写了父类方法后程序运行时需要根据对象实际类型去查找应该调用哪个方法实现这个查找过程叫“动态分派”。它是JVM在运行期完成的比编译期直接确定方法地址要慢一些。当然现代JVM有内联缓存Inline Cache之类的优化大多数情况下这个性能差异小到可以忽略。但如果你写的是极端高性能场景——比如每秒循环上千万次的算法、实时图形渲染的每一帧更新那么在热循环里频繁触发多态调用性能损耗就会被放大。这个坑怎么避呢第一优先保证代码清晰在明确检测到性能瓶颈之后再做优化。第二如果你自己设计一个底层工具类内部频繁调用的方法尽量少用多态可以用final关键字禁止父类方法重写或者用private方法这样编译器/JIT可以更激进地优化。记住多态是写给人看的不是写给机器看的。机器需要的只是速度人需要的是结构。3.2 可读性代码跳来跳去新手真的很崩溃多态有一个被很多人忽略的“隐形成本”阅读成本高。当你看到e.calculateSalary()这样一行代码时你没办法立刻知道它到底执行了哪个类的实现。你得先看e的类型再找到Employee抽象类再根据业务逻辑推测当前运行时e是Manager还是Intern然后去对应的子类里翻代码。如果要查的类有四五层继承关系这趟“翻山越岭”就非常折磨人。有人说“IDE能跳转啊”可跳转出来的是抽象类里的声明你还得手动找具体实现。类少还好类一多就麻烦。所以在实际项目里我见过不少团队因为滥用多态把本来简单的一段业务逻辑拆得七零八落每个类都很“干净”但连起来简直像拼图——少看一个子类都不知道整个流程走的是什么。我的建议是**如果一个多态结构不能让你在5分钟之内讲清楚协作关系那它就太复杂了。**能用简单的if-else解决的问题没必要为了“优雅”硬造一个抽象层。抽象层是有成本的它替你管理“变化”的同时也增加了一层理解负担。3.3 强制类型转换多态的伴生事故用多态的时候父类引用往往只能调用父类中声明过的方法。如果你确实需要用子类特有的方法你得做强制类型转换也就是我们常说的向下转型Employee e new Manager(张三, 8000, 5000); double bonus ((Manager) e).getPerformanceBonus();这种代码一旦多了类之间就会隐含着一种“我知道你实际是谁”的强依赖。更危险的是如果转型错了比如把一个Intern强转成Manager程序运行时会直接抛出ClassCastException程序当场崩溃。所以在写转型代码之前一般要先用instanceof检查实际类型。可一旦你发现代码里到处是instanceof和强制转型就要警惕了这通常说明你的抽象层设计得不够好或者你压根就不该在这里使用多态。多态的目的就是避免调用方关心具体类型如果调用方处处都要关心那不是你的用法有问题就是抽象层选错了。3.4 构造方法里调重写方法最隐蔽的坑这个坑我亲眼见过好几个初学者踩进去爬不出来。假设父类的构造函数里有这样一段代码public abstract class Employee { protected String badgeInfo; public Employee() { this.badgeInfo buildBadgeInfo(); // 调用了一个可被子类重写的方法 } protected String buildBadgeInfo() { return base-badge; } } public class Manager extends Employee { private String level; public Manager(String level) { super(); // 先走父类构造 this.level level; } Override protected String buildBadgeInfo() { return manager-badge- level; // level 还没初始化 } }执行这段代码时会发现badgeInfo的值变成manager-badge-null而不是你预期的manager-badge-Gold。原因在于new Manager(Gold)的时候先执行父类构造函数而父类构造函数里的buildBadgeInfo()被子类重写了Java的动态分派机制会去调用子类的那个版本。但此刻子类自己的level字段还没赋值所以拿到的是null。这就是多态“运行时才决定方法版本”带来的副作用。规避方法很简单构造函数里永远不要调用被子类重写的方法。如果父类构造时确实需要一些可变化的数据建议改用参数传递或者把逻辑挪到子类构造函数中去完成。这类问题编译期不会报错程序也不会立刻崩溃但结果就是不对排查起来特别耗时间。3.5 不是所有东西都能多态成员变量和静态方法这个小陷阱我在做题时都栽过一次。Java里只有实例方法具备多态性成员变量和静态方法是不参与多态的。看下面这段public class Employee { protected String displayName 员工; } public class Manager extends Employee { protected String displayName 经理; } public static void main(String[] args) { Employee e new Manager(); System.out.println(e.displayName); // 输出的是“员工” }听上去很反直觉对吧e明明指向一个Manager对象你访问displayName这个成员变量时得到的却是父类的值。因为成员变量是按“变量的声明类型”来访问的编译期间就绑定了跟运行时对象是谁没关系。静态方法同理“父类引用调用静态方法”时走的也是声明类型的方法实现。所以你要是想依赖多态去切换静态行为逻辑根本不成立。这个知识点虽然看起来像考试题但在调试老代码时非常实用——看到输出跟预期不一样先检查是不是在访问成员变量。4. 综合练习写一个员工薪资展示系统前面讲了这么多现在动手做一道稍微完整的练习。把你学过的封装、继承、重写、多态全部串起来。建议你自己先写一遍再往下看遇到卡住的地方就是你没掌握的知识点正好补一补。4.1 练习需求某公司要开发一个员工信息管理系统的最小模块需求如下有抽象类Employee包含员工姓名name、基础工资baseSalary提供getName()方法。有一个抽象方法calculateSalary()用于计算员工实际工资一个普通方法getInfo()返回员工姓名和实发工资的格式化字符串。三个具体员工类RegularEmployee普通员工工资只有基础工资。Manager经理工资 基础工资 绩效奖金performanceBonus。Intern实习生工资为固定的实习津贴internAllowance不使用基础工资。写一个Company类内部维护一个员工列表提供addEmployee(Employee e)方法。写一个主程序Main创建一家公司加入若干员工遍历所有员工打印每位员工信息并统计公司所有员工的总工资。注意不许在Company内部使用任何instanceof或强制类型转换所有计算必须通过多态完成。这个练习比表面上看起来有讲究。先分析一下需求的考察点第一calculateSalary()是一个抽象方法每个子类都必须实现这是重写的基本功第二Company的addEmployee参数类型是抽象类Employee这就要求你理解“父类引用指向子类对象”第三遍历并调用calculateSalary()时必须有运行期多态才能自动调用到正确的工资计算逻辑第四Intern的工资直接写死津贴值说明子类可以和父类定义的字段行为不一样考验你对抽象方法的理解。4.2 设计思路拿到需求先别急着敲代码。我的习惯是先用文字把类的结构列清楚Employee抽象类 - name: String - baseSalary: double - getName(): String calculateSalary(): double抽象方法 getInfo(): String → 返回 姓名xxx本月工资xxx元 RegularEmployee extends Employee 构造方法(name, baseSalary) calculateSalary(): 返回 baseSalary Manager extends Employee - performanceBonus: double 构造方法(name, baseSalary, performanceBonus) calculateSalary(): 返回 baseSalary performanceBonus Intern extends Employee 构造方法(name) calculateSalary(): 返回 3000固定津贴不理会 baseSalary Company - employees: ListEmployee addEmployee(Employee e) printAllEmployees(): void calculateTotalSalary(): double Main - main(...)这个结构非常直观地展现了多态的使用场景Company类只关心Employee这个抽象类型不关心具体子类是谁。将来公司增加“外包员工”“退休返聘员工”只需要新增一个类Company零改动。4.3 从抽象类到实现类一步步写下代码先写Employee抽象类。注意构造方法的可见性我选了protected让子类可以访问baseSalary字段同时对外提供getName()public abstract class Employee { private String name; protected double baseSalary; public Employee(String name, double baseSalary) { this.name name; this.baseSalary baseSalary; } public String getName() { return name; } public abstract double calculateSalary(); public String getInfo() { return 姓名 getName() 本月工资 calculateSalary() 元; } }接下来是三个子类public class RegularEmployee extends Employee { public RegularEmployee(String name, double baseSalary) { super(name, baseSalary); } Override public double calculateSalary() { return baseSalary; } } public class Manager extends Employee { private double performanceBonus; public Manager(String name, double baseSalary, double performanceBonus) { super(name, baseSalary); this.performanceBonus performanceBonus; } Override public double calculateSalary() { return baseSalary performanceBonus; } } public class Intern extends Employee { public Intern(String name) { super(name, 0); } Override public double calculateSalary() { return 3000; } }注意Intern的写法调用父类构造方法时传入baseSalary 0但calculateSalary()直接返回3000。这没问题因为父类的baseSalary只是一个字段子类重写calculateSalary()后字段有没有用得上不取决于定义而取决于你的实现。这里可能会有人疑惑那直接把baseSalary设成3000不就行了吗也可以但如果语义上是“实习津贴”用一个固定常量更贴近真实业务。然后是Company类import java.util.ArrayList; import java.util.List; public class Company { private ListEmployee employees new ArrayList(); public void addEmployee(Employee e) { employees.add(e); } public void printAllEmployees() { for (Employee e : employees) { System.out.println(e.getInfo()); } } public double calculateTotalSalary() { double total 0; for (Employee e : employees) { total e.calculateSalary(); } return total; } }最后是主程序public class Main { public static void main(String[] args) { Company company new Company(); company.addEmployee(new RegularEmployee(张三, 6000)); company.addEmployee(new Manager(李四, 10000, 8000)); company.addEmployee(new Intern(王五)); company.addEmployee(new Intern(赵六)); company.printAllEmployees(); System.out.println(公司总工资 company.calculateTotalSalary() 元); } }运行结果姓名张三本月工资6000.0元 姓名李四本月工资18000.0元 姓名王五本月工资3000.0元 姓名赵六本月工资3000.0元 公司总工资30000.0元这个练习的全部精华就在Company类的两段循环里它不知道也不关心列表里到底坐着什么员工只管挨个调用calculateSalary()。程序跑起来之后JVM自己找对方法该加奖金的加奖金该发津贴的发津贴。你回头再想想最初那版if-else的SalaryService是不是感觉完全不一样了4.4 练习完成后再给自己加两道思考题如果做完了觉得没难度这里有两道思考题可以自查第一道如果公司增加一个PartTimeEmployee兼职员工工资按小时计算需要在小时间数和时薪的基础上算总额。你会怎么改正确做法是新建一个类继承Employee重写calculateSalary()然后把Company和Main里对应的创建逻辑加上去。如果你发现自己忍不住想去改Company类说明你对多态的优势还没完全消化。第二道如果Employee抽象类的getInfo()里不是调用calculateSalary()而是直接访问baseSalary字段会出现什么问题答案是所有子类打印出来的工资都是baseSalary原始值经理的绩效奖金、实习生的固定津贴全都体现不出来。这个问题的本质就是提醒你——多态只会发生在方法调用上字段不管。想让行为跟着对象走就必须走方法。5. 练习常见错误与自查清单这些坑比你想的更典型每次给初学者讲解这道练习我都会反复看到同几类错误。这些错误非常典型基本覆盖了多态学习的大部分雷区我把它整理成一张自查清单。5.1 常见错误一重写签名写错了变成了重载比如有人把calculateSalary()写成了public double calculateSalary(int month) { return baseSalary; }参数列表从无变成了int month。编译器不报警因为这不满足重写条件Java会认为你在子类里的方法是一个全新的方法。结果Company循环里调用的calculateSalary()还是父类的抽象实现——如果父类实现了的话。但这里抽象方法没有实现子类再用这个签名编译器就会直接报ClassCastException的兄弟错误子类没有被抽象方法完全实现类无法编译通过。这种错误其实还算好因为编译器给了明显提示。麻烦的是父类方法不是抽象方法的情况比如public class Employee { public double calculateSalary() { return 0; } } public class Manager extends Employee { public double calculateSalary() { return baseSalary performanceBonus; } }这时候你写错了签名比如加了一个参数编译不会报错但运行时Company永远调用的是父类的calculateSalary()结果永远是0排错能排一晚上。避免这个坑最有效的办法在子类重写方法上加上Override注解。如果你写错了签名没有构成重写编译器会立刻警告你就能在编译期把问题拦截下来。这是每个Java程序员都应该养成的小习惯。5.2 常见错误二在Company里忍不住用instanceof有个学员写的Company类长这样public void printAllEmployees() { for (Employee e : employees) { if (e instanceof Manager) { System.out.println(((Manager) e).getManagerInfo()); } else if (e instanceof Intern) { System.out.println(实习生 e.getName()); } else { System.out.println(e.getInfo()); } } }这种做法不是完全不能用但它完全违反了这道练习的设计意图。你一旦开始判断具体类型就说明getInfo()这个方法在抽象层里设计得不够用你就跑去依赖具体子类。比如这里如果你需要“经理打印专属信息”更好的方案是在抽象类里把getInfo()也设计成可重写的让Manager自己去打印专属内容Company还是无脑遍历调用getInfo()。这样代码会更干净而且Company不需要理解业务细节。5.3 常见错误三把多态当成“到处建父类”的理由反方向的问题也很多。有的同学练完多态之后觉得“哇太强了”二话不说把所有类都塞到一个抽象父类下面哪怕类与类之间八竿子打不着也硬造继承关系。比如搞一个抽象类BaseObject让Car、User、Order都继承它里面的抽象方法叫process()。这看起来很“多态”实际上子类之间毫无共性抽象方法的签名完全是为了凑而凑真正调用的时候要么空实现要么写一堆错误逻辑。多态必须建立在“确实是同一类事物的不同形态”这个语义基础上Dog和Cat都是Animal没问题但如果你为了让代码“看起来面向对象”而硬造父子关系项目后期刹车都刹不住。5.4 自查清单做这道练习的过程中你不妨对照下面的清单过一遍每个子类是否都完整实现了抽象方法有没有漏掉OverrideCompany类里有没有出现instanceof或强制类型转换出现了就说明设计有问题。Intern的baseSalary传0是否合理如果改成传3000又会有什么不同把ListEmployee的泛型改成ListManager程序还能跑吗为什么如果在Employee里新增一个抽象方法所有子类是否都被强制要求实现这样的设计是好是坏你能否在不改Company类的前提下给公司加一种新的员工类型这些问题的答案如果你都能说清楚多态这个知识点就算过关了。5.5 从练习到实战接口是不是比抽象类更适合多态练习里用的是抽象类但实际上Java里还有一种更常用的方式——接口。很多同学会混淆“什么时候用抽象类什么时候用接口”。我的个人经验是如果多个类之间存在公共代码和字段用抽象类如果只是要约束“具备某种能力”用接口。比如Animal抽象类可以持有name、age这些公共字段而Swimmable接口只规定你“必须能游”至于怎么游、游多快接口不管。从“从零开始学Java”的进度来说你现在只需要知道两者都可以实现多态等学到接口那一篇再去深究。如果你在看框架源码或者别人的项目时看到一个接口类型的变量调用了接口里的方法底层逻辑跟我们刚才做练习时是完全一样的——程序在运行时动态决定由哪个实现类来干活。6. 我自己在真正掌握多态之后的一点体会最后多说几句不该写在教科书里的话。刚学多态那阵子我老有一种“用上了多态就代表我很强”的错觉动不动就抽象出一个父类哪怕只有一个子类也要建一层抽象。后来写的东西多了才慢慢明白多态真正值钱的地方不在于“用”它而在于“什么时候不用它”。一个经验是抽象层是用来对抗变化的不是用来表演优雅的。如果你的代码只有两个类而且看不到新增类型的可能那直接写具体类比硬上多态舒服得多。反过来如果你的业务明确要扩展一套“同类不同实现”的组件比如报表导出、消息推送、支付渠道那么多态能帮你把扩展成本降到非常低。第二个经验是代码写完之后每隔一段时间可以回头看一眼自己写的类结构。如果一个抽象类下面只有一两个子类而且抽象方法常年没有被新实现覆盖那这层抽象十有八九是多余的可以大胆地折叠掉。真正合理的抽象是“加新功能时你根本不用思考就能找到插入点”而不是“为了让代码显得灵活专门建一堆关系”。第三个经验跟阅读有关。当你看到别人的代码里出现抽象类引用、接口引用时不要急着跳进去看实现。先看业务调用方做了什么再看抽象层提供了什么能力最后才按需点开具体实现。只要调用方那层逻辑足够清晰多态带给你的就是一种“阅读上的舒适”——你不需要关心细节也基本能猜到流程因为抽象方法的名字已经把意图写在脸上了。这一篇没有新的语法要背但你掌握的东西会在后面学集合、学框架时反复出现。如果你能独立把练习里的代码写出来并且想清楚第5节那几道思考题那“多态”这一关就真的过了。下一篇我们继续往前Java这个世界的“接口”篇章已经在向你招手了。
