★ FEATURED ARTICLE 多态是Java面向对象三大特性封装、继承、多态里最绕的一个。很多人学到这里概念都背得滚瓜烂熟但一写代码就蒙或者看懂例子但不知道为什么要这么做。这篇我尽量把多态掰开揉碎从底层原理到实战案例都过一遍看完应该能解决你大部分疑惑。1. 为什么几乎所有初学者第一次遇到多态都会卡住1.1 最先绊倒我的两个方法同名的直觉陷阱我刚学多态那会儿特别容易被同一个方法不同对象执行不同行为这句话带偏。脑子里浮现的就是写两个名字一样的方法然后根据传参不同走不同逻辑这就是我理解的多态。结果一写代码发现方法重载编译期就确定了运行时报错了也不知道哪里错非常尴尬。后来我意识到初学者容易被多态这个翻译词误导。中文的多态听起来像是多种状态多种形态容易往数据上有不同状态那个方向想。但实际上Java里的多态更像是**同一份接口契约多种行为实现**——它关心的是调用谁的方法这件事能在运行时才确定下来而不是在编译时就被焊死。如果没有真正理解这个区别后面看Spring、看各种框架源码会非常痛苦。框架代码里到处都是接口引用指向实现类对象你如果不理解运行期绑定看代码的时候会觉得这到底是哪个实现跑了完全懵圈。1.2 没有多态的世界是什么样子理解一个概念最好的方式是先知道没有它世界会怎样。我拿一个最常见的场景举例你现在要给三种支付方式做结算——微信、支付宝、银行卡。没有多态的时候你的代码大概是这样的public class OrderService { public void pay(String payType, double money) { if (wechat.equals(payType)) { System.out.println(使用微信支付 money 元); // 微信支付特有逻辑 } else if (alipay.equals(payType)) { System.out.println(使用支付宝支付 money 元); // 支付宝支付特有逻辑 } else if (card.equals(payType)) { System.out.println(使用银行卡支付 money 元); // 银行卡支付特有逻辑 } else { throw new IllegalArgumentException(未知支付方式); } } }这段代码刚写完看起来还挺爽简单粗暴。但假如后面要加京东白条、加Apple Pay、加数字货币呢每一个新支付方式都要往pay方法里塞一个else if。这个方法越来越长改一次全盘测试一次改错了影响所有支付方式——这就是典型的面向过程式扩展。而多态要解决的问题就是把这个改一处影响所有的模式变成加一个类就行的模式public interface Payment { void pay(double money); } public class WechatPay implements Payment { Override public void pay(double money) { System.out.println(使用微信支付 money 元); } } public class Alipay implements Payment { Override public void pay(double money) { System.out.println(使用支付宝支付 money 元); } } public class CardPay implements Payment { Override public void pay(double money) { System.out.println(使用银行卡支付 money 元); } }调用侧呢不需要知道具体是什么支付方式只需要面向接口public class OrderService { public void pay(Payment payment, double money) { payment.pay(money); } }新增一种支付方式时原来的代码一行都不用改只是额外多写一个实现类然后在使用方的地方传入不同的对象而已。这才是多态带来的核心价值面向接口编程扩展开放、修改关闭。2. 多态的三块基石继承、重写、动态绑定多态不是凭空发生的Java里要形成多态至少需要满足三个条件。这三个条件缺一个你写的代码看起来像多态实际上根本跑不起来。2.1 基石一继承关系是前提is-a关系多态的前提是要有继承或者接口实现关系。父类引用指向子类对象或者接口引用指向实现类对象才谈得上一个引用多种形态。没有这个关系编译器第一关就过不去。这里要注意一个点Java的继承是单继承一个类只能有一个父类但是可以实现多个接口。所以实际项目里接口作为能力契约比抽象类作为继承基类用得更频繁。因为接口更灵活一个类可以实现多个接口对应多种协议而继承只能一条路走到黑。我自己的习惯是能用接口抽象行为就用接口抽象类更多用来作为模板方法模式的载体两者分工不同。2.2 基石二方法重写的那些隐藏规则重写Override不是随便写个同名方法就行Java对重写有一套完整的约束方法签名必须一样方法名、参数列表完全一致。返回值类型可以相同也可以是父类返回类型的子类型协变返回类型。访问修饰符子类方法的访问权限不能比父类更严格。父类是public的子类不能改成protected。反过来说父类是protected的子类升成public没问题。抛出的异常子类可以抛父类异常的子类也可以不抛但不能抛新的更宽泛的检查异常。初学者最常踩的就是访问权限那个坑。有个同学在项目里把父类public方法重写成了private结果编译直接报错他还愣了半天不知道怎么回事。编译器告诉他attempting to assign weaker access privileges意思就是你把访问权限收紧了。重写的本质意义在于子类用自己的实现覆盖父类的行为但这种覆盖又不能破坏父类定义的契约。更具体的说法是里氏替换原则——父类出现的地方用任意子类替代都不会出错。这也是多态的底层契约基础。2.3 基石三动态绑定才是多态的灵魂很多人把继承关系当成多态的全部其实大错特错。只有继承关系但没有动态绑定你调用子类方法时依然只会走父类实现。动态绑定在Java里也叫运行期多态。它的核心机制是编译的时候编译器只看到引用变量的类型父类类型所以它检查方法是否存在就以父类为准但真正运行的时候JVM会根据实际对象的类型来决定调用哪个方法。Java中方法调用默认是虚调用除非你显式加了final或者方法本身就是private/static的。JVM在运行期通过方法表vtable来定位实际应该调用的方法地址。这里我建议你动手做个实验来加深理解。写一个父类和一个子类各自在方法里用getClass()打印当前对象的实际类型。然后父类引用指向子类对象调用方法。你会发现方法体里getClass()返回的是子类类型——这就说明虽然是父类引用在调方法但真正执行逻辑的是子类对象本身。术语层面这个叫动态分派Dynamic Dispatch。编译期能确定调用哪个方法的那一套体系叫静态分派Static Dispatch比如下面要说的方法重载。3. 重载和重写两个最容易混淆的概念对比3.1 编译期多态方法重载的真相很多人把方法重载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; } public int add(int a, int b, int c) { return a b c; } }调用的时候传两个int就走第一个传两个double就走第二个传三个int就走第三个。这些在编译期就确定了运行的时候不会变。要注意的是编译器在选择重载版本的时候有一个人家叫最匹配原则的机制。比如你传两个int进来但类里只定义了double版本的重载编译器会自动做类型提升把int当double用调用double版本。如果同时存在int版本和double版本那传int的时候优先选int版本不会选double版本。这种匹配顺序是编译器内部定死的规则没必要死记但你要知道有这个机制存在调试奇怪的调用关系时心里有数。3.2 运行期多态方法重写的特性真正我们平时说的Java多态指的还是重写Override带来的运行期多态。它发生在继承关系之间子类重写父类的方法父类引用指向子类对象运行的时候实际调用子类方法。这个我在上一节已经讲过它是JVM运行期动态分派的产物。这里有个很有意思的现象如果子类重写了父类的方法但你的调用代码是父类引用指向子类对象编译阶段调用的版本是父类的运行阶段的版本却是子类的。很多初学者在这种场景下用IDE单步调试会看到方法栈里跳来跳去觉得编译器骗我其实这就是动态绑定的正常表现。3.3 区分指南一张表说清两件事对比项方法重载Overload方法重写Override发生位置同一个类内子类与父类之间方法名相同相同参数列表必须不同必须完全相同返回类型不限制可以不同相同或是父类返回类型的子类型Java 5后支持协变返回访问修饰符不限制不能比父类更严格但可以更宽松异常声明不限制不能抛出新的更宽泛检查异常可以缩小或删除绑定时机编译期静态分派运行期动态分派关键字无强制要求常见配合Overload注释建议加Override让编译器帮你校验本质目的提供一组功能相似但参数类型不同的方法子类覆盖父类默认行为满足多态扩展我自己记忆的方法是载是承载多个方法发生在同一类内部写是覆盖重写发生在继承体系之间。两个词的动词重心完全不同。有一个最常见的面试题陷阱父类中有一个void run()方法子类中写了一个int run()方法。这是重载还是重写答案都不合法。参数相同的情况下返回类型不同既不能算重载参数要不同也不算重写返回类型不兼容所以编译器直接报错。这种题考察的就是对两条规则边界的精准理解。4. 上下转型多态里的戴面具与卸面具4.1 向上转型自动发生的缩小视野父类引用指向子类对象这个操作叫向上转型。它总是安全的因为子类一定包含父类的全部能力所以子类对象装成父类对象是没问题的只不过会丢失子类特有行为的访问权限。打个比方你把一个iPhone塞进一个手机的盒子里你在外面看它就是个手机能打电话能上网但你掏不出它的全局搜索和灵动岛。向上转型就是戴面具——暴露父类接口隐藏子类特性。Payment payment new WechatPay(); // 向上转型 payment.pay(100); // 调用的是子类WechatPay的pay方法这个转换是安全的不需要任何显式操作Java自动帮你做了。它也是多态的最典型表现形式。4.2 向下转型危险但必要两种方式对比把父类引用强制转回子类引用这个叫向下转型。它不总是安全的因为父类引用背后实际指向的不一定是那个子类对象。就好比你从盒子里掏出一个手机想当然认为是iPhone结果掏出来发现是个安卓机于是调用iOS专属功能必然出事。Payment payment new Alipay(); // 下面这种写法运行期会抛 ClassCastException WechatPay wechatPay (WechatPay) payment; wechatPay.someWechatOnlyMethod();因为这个引用实际指向的是Alipay对象你强行要把它当WechatPay用JVM在运行期检查类型不合规直接抛异常。所以向下转型的标准做法是先用instanceof判断if (payment instanceof WechatPay) { WechatPay wechatPay (WechatPay) payment; wechatPay.someWechatOnlyMethod(); }Java 16之后你可以用模式匹配简化写法if (payment instanceof WechatPay wechatPay) { wechatPay.someWechatOnlyMethod(); }这个特性省掉了强转代码看起来清爽很多。4.3 instanceof 的辨析技巧与性能提示instanceof的语义是检查对象实际类型是否能与右侧类型匹配包括继承链和接口实现链。但很多人忽略了一个细节左侧是null时instanceof直接返回false不会抛异常。这可以省去先判空再判类型的双重判断。不过也别滥用instanceof。如果你在代码里到处写if (x instanceof A) ... else if (x instanceof B) ...那你等于又走回了面向过程的老路。多态本身的价值就是消灭这种类型判断分支——正确的做法是把判断该做什么交给对象自身的方法去表现。如果在你的业务代码里大量出现instanceof分支通常意味着你的抽象接口设计有缺陷或者你正在用多态做它不该做的事。5. 一个贯穿全程的案例从需求变化看多态的现实收益5.1 需求从3个变成10个时的代码演变我直接用一个真实场景来演示多态怎么帮你省事。假设我们在做一个消息通知系统最开始只需要发送邮件和短信两种通知。面向过程写法public void notifyUser(String type, String message) { if (email.equals(type)) { System.out.println(发送邮件通知 message); // 连接邮箱服务器、构造HTML、带附件等一堆逻辑 } else if (sms.equals(type)) { System.out.println(发送短信通知 message); // 连接短信网关、处理签名、字数限制等一堆逻辑 } // 每加一个渠道这个方法就多一个分支方法体越来越长 }多态写法public interface Notifier { void send(String message); } public class EmailNotifier implements Notifier { Override public void send(String message) { System.out.println(发送邮件通知 message); // 邮件专用逻辑 } } public class SmsNotifier implements Notifier { Override public void send(String message) { System.out.println(发送短信通知 message); // 短信专用逻辑 } }调用方public void doNotify(Notifier notifier, String message) { notifier.send(message); }这两种写法在只有2种渠道时看不出多大差别if-else甚至更直观。但项目需求很快变了要支持站内信、微信服务号、钉钉机器人、企业微信、App推送。每加一个渠道面向过程的notifyUser方法就多一个else if分支而且里面还可能塞入几十行初始化代码。到第五个渠道时这个方法已经变成两三百行的上帝方法光阅读成本就让人崩溃。多态版本的扩展是每加一个渠道就加一个实现类调用方一行不需要改。5.2 多态配合工厂模式的效果既然调用方面向接口那到底new哪个实现类出来就成了一个需要解决的问题。这种问题最常用的解法是工厂模式。虽然这篇文章重点不是设计模式但我强烈建议走到多态这一步后马上去学习工厂模式因为这俩是黄金搭档。简单写一个小工厂public class NotifierFactory { public static Notifier create(String type) { return switch (type) { case email - new EmailNotifier(); case sms - new SmsNotifier(); case wechat - new WechatNotifier(); case dingtalk - new DingtalkNotifier(); default - throw new IllegalArgumentException(未知通知类型); }; } }调用方只依赖工厂和接口Notifier notifier NotifierFactory.create(config.getNotifyType()); notifier.send(message);今后渠道再多NotifierFactory.create方法分支变多但通知的调用逻辑完全不会蔓延。项目里那些新增渠道要改几个文件的问题被压缩到了1个工厂1个实现类。5.3 对比如果不用多态代码会变成什么样没用多态的典型症状是部门里每个人的工具类里都有一套自己的if-else通知逻辑改动一个公共行为要全局搜索所有调用点漏一个就出线上事故。用多态重构后核心的通知行为只剩一份契约所有实现围绕契约展开调用侧无感知替换实现。这种替换能力在多态的世界里有一个专门说法叫开闭原则——对扩展开放对修改关闭。我并不是说所有场景都要硬用多态。只有2个分支且未来明确不会扩展的系统用if-else没什么大不了。但只要你预判到这类行为以后会持续扩展趁早抽象接口用多态管理后面你会感谢当初的决定。6. 多态的那些坑我踩过的和见过的6.1 坑1静态方法真的不参与多态静态方法是类级别的挂在类上不走对象方法表。所以你在子类里重写一个静态方法其实只是写了一个完全相同签名的新静态方法这叫隐藏hide不叫重写。调用时绑定哪个版本看的是引用变量的编译期类型而不是实际对象类型。public class Parent { public static void hello() { System.out.println(parent static); } } public class Child extends Parent { public static void hello() { System.out.println(child static); } }当你写这段代码时Parent p new Child(); p.hello(); // 输出的是 parent static不是 child static这是新手很容易踩进去的隐形坑因为hello()方法看起来是被重写了IDE也不报警实际运行结果和动态绑定却不一样。关键点就一句话——静态方法跟着引用类型走实例方法跟着对象类型走。6.2 坑2private和final方法看似多态却非多态private方法只作用于当前类内部子类里写同名的private方法跟父类毫无关系纯属碰巧同名。final方法不允许子类重写JVM在调用时也会做优化处理不会走动态分派。这两个关键字有一个共同意义方法不再具备扩展性。如果你设计一个类明确不希望子类篡改某个核心行为就该把它设为final。反过来如果你写的是框架底层方法没加final但子类又改错了行为很容易产生诡异bug。我见过一个真实案例有人在业务父类里定义了save()方法没加final结果子类为了保存前先做校验重写了这个方法但忘掉了父类里一些关键状态更新逻辑导致数据错乱。经验教训就是设计父类的时候该锁定的行为必须加final别给子类留误操作的空间。6.3 坑3子类构造器里调用会被覆盖的方法这个坑症状隐蔽但破坏力很强。父类构造器里如果调用了一个可被重写的方法那么在new子类对象的时候由于父类构造器先执行它会触发子类中重写后的方法——但此时子类尚未初始化完成字段可能还是默认值。这会导致一个莫名奇妙的结果。public class Parent { public Parent() { init(); // 调用了可被重写的方法 } protected void init() { System.out.println(parent init); } } public class Child extends Parent { private String name 张三; Override protected void init() { System.out.println(child init, name name); } }实例化new Child()输出结果是child init, namenull而不是张三。因为父类构造器执行时子类的字段赋值语句还没跑name还是null。这个问题的规避方案是在构造器里只调用private或final方法不要调用可能被子类重写的方法。这也是很多框架源码在构造器中做初始化时总是调private方法的原因——不是巧合是刻意规避这个坑。6.4 坑4滥用多态导致类爆炸多态不是越多越好。有些人喜欢给每个行为都建一个接口、一堆实现类结果项目里的类多到比业务实体还多。新手看老项目常有这种感觉咋这么多类我该看哪个实话说我也经历过这个阶段。后来我给自己定了几个准则一个行为如果只有一种实现且可以预见的未来都只有一种实现就先不用接口等出现第二种实现的前一天再抽接口也不晚。接口是为变化而生的没有变化压力就不必动用这个武器。多态最大的成本是代码跳转的间接性看代码时从一个类跳到另一个类心智负担是真的存在的。7. 学习多态的实用心法框架源码是最好的教科书7.1 三个使用准则从会写到会设计学多态不能停留在会写继承、会重写方法这个层面更应该学会的是什么时候用、怎么用。我自己的经验总结三条第一面向接口编程而不是面向实现编程。方法入参、字段类型、方法返回类型尽量使用抽象类型这样将来替换实现时改动面最小。第二里氏替换原则是衡量多态品质的标尺。父类能做的事子类都应该能顶上去。如果你的子类在替换父类后出现行为异常或抛异常那这个继承关系本身就是有问题的多态再好也救不了。第三慎用向下转型。代码里向下转型越少说明你的抽象质量越高。动不动就强转子类再调方法通常意味着接口设计缺方法该补的补上。7.2 从框架源码里学多态的应用形态很多人学完多态语法不知道真实项目到底是什么样子尤其是没做过大型项目的情况下。我的建议是别闷头刷题直接去读常用框架的源码。以Spring为例ApplicationContext是一个接口你平时用到的ClassPathXmlApplicationContext、AnnotationConfigApplicationContext都是它的实现类。你在代码里声明的往往是ApplicationContext ctx new AnnotationConfigApplicationContext(...)这本身就是最标准的多态用法。再比如HandlerInterceptor接口你写各种拦截器时实现这个接口Spring在调用拦截器的preHandle方法时拿到的引用类型是接口但实际执行的是你写的实现。哪怕你不深究细节只要能在这段调用里看到接口引用指向实现类对象、运行期动态绑定、面向接口编程这三件事你对多态的认识就已经进阶了。7.3 练习建议把三段代码改成多态结构光看不练多态永远只是别人的知识。我建议你找三段足够脏的if-else代码来练手第一段是一个简单的计算器加减乘除全用if-else分支判断运算符改成多态后分出一个Operation接口每种运算一个实现类。第二段是一个订单折扣计算器根据用户积分等级计算折扣改成策略模式加多态你会发现将来增加新等级会员的代价变得极低。第三段是把自己平时写过的工具方法里凡是出现根据类型分支执行不同代码的地方全部重构为多态结构然后对比一下改了哪些文件、动了多少行你就能感受到多态的复用价值。我当年是拿自己的个人博客项目练的把日志记录、缓存存储、消息推送都改成了接口加实现类的结构。改完最大的感受是代码像变成了乐高积木一样可以拆、可以拼、可以替换而不是一坨必须整体推翻的湿泥巴。等你练到这种手感多态这关就算真正过了。
阅读完成 · 觉得有帮助？
