1. 为什么需要抽象类一个支付系统的设计困局先从一个我实际做过的项目说起。那是一个电商系统的支付模块上线第一天只接了微信支付代码结构很简单一个PayService里面一个pay()方法内部调微信SDK签名、下单、回调一气呵成。整个类也就七八十行看起来没什么问题。但第二个月需求就来了接入支付宝。第三个月又要加银联云闪付。我当时的第一个念头是复制粘贴把PayService拷一份改成PayServiceForAli里面换一套SDK调用。开头确实快但很快就发现不对劲——每次改动支付回调逻辑要同步改三个地方每个类里的参数校验代码几乎一模一样只是签名字段不同最恶心的是测试用例要写三份每份的逻辑还没什么区别。这时候我才意识到普通的类继承解决不了这个问题。如果我写一个父类BasePayService把公共的下单、验签、回调处理逻辑都放进去子类继承它并重写各自的部分看起来可以。但如果父类里的某个方法没有合理默认实现——比如pay()方法微信和支付宝的请求参数、加密方式、接口地址完全不同父类根本不知道该往里面填什么。让父类方法返回空或者抛异常那是在给未来的自己埋雷。提示写一个方法体为空或直接throw new UnsupportedOperationException()的父类方法本质上就是用普通类的语法强行模拟抽象方法这种设计会让子类忘记重写时静默出错非常危险。这其实就是抽象类和抽象方法诞生的场景父类只声明我是谁、我要做什么不关心具体怎么做。子类必须自己给出实现。你可以在Java、C#、PHP、Kotlin、TypeScript里都看到这个机制我下面的示例以Java为主但思路是通用的。1.1 从普通类继承说起——公共代码能解决什么问题要理解抽象类先得理解普通继承的边界。普通继承解决的是复用实现的问题子类是父类的一种特殊形态直接继承父类写好的方法体改一改、加一加就形成了新类。public class Animal { protected String name; public Animal(String name) { this.name name; } public void eat() { System.out.println(name 正在吃东西); } } public class Dog extends Animal { public Dog(String name) { super(name); } public void shout() { System.out.println(name 汪汪叫); } }这套逻辑用在Dog上没问题狗确实会吃东西父类的eat()实现完全通用。但如果你要定义一个Bird类问题就来了鸟怎么吃东西不同的鸟吃的东西差太多了麻雀吃虫子鹦鹉吃谷物企鹅吃鱼。Animal.eat()的这个实现往哪个方向放都不对。另一个更麻烦的场景是这个行为对当前类型来说根本不存在合理实现。假设你在做一个图形系统所有的图形都有getArea()这个方法但面积怎么算完全取决于具体图形。圆形用πr²矩形用长乘宽三角形用底乘高除以二。你在Shape这个父类里怎么写getArea()写什么都没意义。这种情况下继承一个已有实现的思路就走不通了。你需要的不是复用父类代码而是强制子类自己实现。抽象方法就是干这个的——它只有方法签名没有方法体不给任何默认实现子类不重写就编译不过。1.2 抽象类登场把该做的事和怎么做分开抽象类的定义方式很简单在类声明上加abstract关键字类里可以包含抽象方法也可以包含普通方法。public abstract class AbstractPayService { // 抽象方法只定义流程不写实现 public abstract String buildSignParams(Object order); public abstract boolean verifyCallback(String sign, String data); public abstract String requestPayUrl(Object order); // 普通方法所有子类共享的公共模板逻辑 public boolean processPay(Object order) { String params buildSignParams(order); boolean verified verifyCallback(params, test-data); if (!verified) { return false; } String url requestPayUrl(order); System.out.println(生成的支付链接是 url); return true; } }这段代码里你能看到最核心的分工逻辑processPay()是一个模板它规定了支付流程的骨架——先构建参数再验签再请求支付地址。但具体每一步怎么做它完全不管全部甩给抽象方法让子类决定。这就是把该做的事和怎么做分开的典型结构。子类只需要关心自己的差异化部分public class WechatPayService extends AbstractPayService { Override public String buildSignParams(Object order) { // 微信支付MD5签名、appId、mchId... return appIdxxxmchIdyyysignzzz; } Override public boolean verifyCallback(String sign, String data) { // 微信回调验签逻辑 return true; } Override public String requestPayUrl(Object order) { // 微信下单接口调用 return https://api.mch.weixin.qq.com/pay/unifiedorder; } }写到这里你应该能感觉出来了抽象类在设计层面承担了两种职责一是约束子类必须提供什么二是自己保留什么共通的实现给子类继承。这两点一组合就解决了支付系统那类问题的核心矛盾——一堆类长得很像但又有各自不同的关键行为。光靠普通继承你得靠覆盖方法去覆盖掉父类的不合理实现靠抽象类你直接从设计上就杜绝了父类给出错误默认值的可能性。2. 抽象类和普通类的本质差异五个维度的逐项对比网上讲抽象类的文章很多但大多数只讲抽象类不能被实例化这一条然后就跳到接口对比去了。其实抽象类和普通类的差别远不止能不能new这么简单下面我从五个维度拆开来讲这些差异在面试和实际开发中都是高频考点。2.1 实例化为什么抽象类不能newnew一个普通类本质上是给对象分配内存并执行构造方法。但抽象类里可能包含抽象方法抽象方法没有方法体意味着这个对象如果被创建出来调用某个方法时根本不知道该执行什么代码。为了避免这种不完整对象出现编译器直接禁止了对抽象类的实例化。// 编译报错Shape是抽象的无法实例化 Shape shape new Shape();但这不意味着你不能用抽象类型去声明变量。恰恰相反用抽象类作为引用类型是抽象类最典型的用法之一。你可以通过一个AbstractPayService类型的变量去引用任何子类对象AbstractPayService service new WechatPayService(); service.processPay(order);运行时的多态就在这里体现调用processPay时内部实际执行的是WechatPayService重写后的buildSignParams和requestPayUrl。面向抽象编程的好处是将来你加一个AlipayPayService只需要换一行new的对象即可调用方代码一行都不用改。2.2 方法体抽象方法为什么不能有花括号普通方法声明后必须带方法体哪怕方法体是空的public void doNothing() { // 空方法体合法 }抽象方法则恰恰相反声明后必须用分号结束不能写花括号// 正确写法 public abstract void doSomething(); // 编译报错抽象方法不能有方法体 public abstract void doSomething() { System.out.println(...); }这个规则背后的原因直白得很一旦抽象方法有了方法体它就和普通方法没有区别了子类就不会被强制要求重写它抽象也就名存实亡。Java规范特意把缺省方法体作为抽象方法的语法标识这样编译器能一眼识别出哪些方法必须由子类实现哪些方法是可选的。2.3 构造器抽象类竟然还能有构造方法这可能是抽象类里最反直觉的规则了抽象类不能new但可以定义构造方法。很多人第一次看到下面这段代码会愣住public abstract class BaseService { protected String appId; // 抽象类居然有构造方法 public BaseService(String appId) { this.appId appId; System.out.println(抽象类的构造方法执行了); } } public class WechatService extends BaseService { public WechatService(String appId) { super(appId); } }这个构造方法有什么用答案是为子类服务。当你new WechatService(wx123)时Java的实例化流程会先调用父类的构造方法再调用子类的构造方法。抽象类不能自己创建对象但它可以完成子类对象中属于父类部分的初始化工作。上面这个例子里appId字段被赋值就是抽象类构造方法在起作用。这也提醒你一件事如果你在抽象类里定义了带参构造方法子类构造方法里必须显式调用super()否则编译报错。这是新手容易踩的坑。2.4 访问修饰符抽象方法能用private吗先直接说结论抽象方法不能用private修饰也不能用static修饰不能用final修饰。理由各自不同private方法只在本类可见子类根本看不到那强制子类重写就无从谈起。static方法属于类本身不参与实例化abstract要求子类实现实例方法两者语法上就互相矛盾。final方法不允许被重写而抽象方法存在的意义就是要被重写天然冲突。相对的抽象方法可以用public或protected修饰而且从Java 8开始接口里的默认方法已经实现抽象类里的抽象方法还可以用package-private即不写修饰符限定访问范围。实际开发中我建议优先用protected因为抽象方法本质上是给子类用的约定protected既保证子类可见又不会过度暴露到外部。2.5 子类的强制与自由重写规则的边界这是一个经常被忽视的关键细节子类继承抽象类后如果不实现所有抽象方法那么子类自己也必须是抽象类。// WechatService只实现了两个抽象方法还有一个没实现 // 如果WechatService不声明为abstract编译直接报错 public abstract class WechatService extends AbstractPayService { Override public String buildSignParams(Object order) { return wechat-sign; } Override public boolean verifyCallback(String sign, String data) { return true; } // requestPayUrl没有实现所以WechatService必须是抽象的 }这条规则的逻辑是完整的抽象类定义了未完成的能力清单子类继承后要么完成所有任务变成可实例化的具体类要么继续保留未完成任务自己也变成抽象类。不存在中间地带。你可以让抽象子类只实现一部分然后继续往下传最终总得有一个具体子类把账结清。为了让你看得更直观我用一个表格总结这五个维度的差异对比维度普通类抽象类实例化可以直接new禁止new只能由子类实例化方法体所有方法都必须有方法体可包含无方法体的抽象方法构造方法正常定义正常调用可定义但只在子类实例化时被调用抽象方法访问性不存在抽象方法可用public/protected不可用private/static/final子类约束子类按需重写方法子类必须实现所有抽象方法否则自身也得是抽象类3. 抽象方法的隐藏规则修饰符、重写与多态的连锁反应很多教程把抽象方法这条讲得很浅只提方法没有方法体就过去了。但实际写代码的时候抽象方法背后牵着一堆连锁规则随便一个违背就是在编译器的雷区里跳舞。3.1 abstract和哪些修饰符天生相克刚才第2.4节已经提到了private、static、final这三个与抽象方法相克的修饰符。但还有几个隐藏雷区值得展开说说。abstract方法不能和synchronized一起用。原因很巧妙synchronized锁的是具体方法的执行代码但抽象方法没有方法体谈不上同步什么所以JDK直接禁止这种写法。可如果你在抽象类里定义了一个普通方法并用synchronized修饰那是完全合法的。我见过不止一次有人想在抽象方法上加同步锁控制并发访问结果编译报错后一脸懵。abstract方法不能和native一起用。native是Java调用本地C/C方法的修饰符它表示方法实现在其他语言里和abstract的方法实现在子类里属于两种完全不同的生存方式。编译器禁止两者同时出现因为无法判断到底应该去子类找实现还是去本地库找实现。abstract方法不能和strictfp一起用。这个修饰符现在很少见了它用于控制浮点数计算的精度一致性作用于方法或类。在抽象方法上使用没有任何意义因为方法没有实现代码谈不上浮点切确性的控制。最后再补一个abstract本身只能用于类和方法不能用于变量、构造器或代码块。你可能会想给一个字段加abstract表示子类必须提供这个字段语法上不支持。想要达到类似效果只能通过抽象方法去间接实现比如定义public abstract String getConfigKey()而不是抽象一个字段。3.2 子类不实现抽象方法的后果前面第2.5节说到了不实现就变成抽象类。这里我再补充一个真实的项目教训我曾经把一个基础业务类设计成抽象类里面放了三个抽象方法觉得子类肯定会实现。结果半年后有人写了一个新子类只实现了其中两个因为偷懒没有声明为abstract编译直接报错。那人就机智地补了个abstract关键字让编译通过。结果这个类根本没法被实例化单元测试一跑就崩排查了好久才发现问题。这种拿abstract来逃避实现的写法在团队协作里是致命的。抽象方法的意义在于强制约束你绕过约束就等于给自己挖坑。正确的做法永远是要么老老实实把方法都实现了要么重新审视抽象方法的设计是不是合理是不是这个方法根本不应该出现在这个抽象类里。3.3 抽象类里的普通方法模板方法模式的基石抽象类里面不光能放抽象方法还能放大量普通方法。这些普通方法可以直接拥有完整实现子类可以继承它们也可以重写它们。这种抽象方法约束骨架、普通方法提供默认逻辑的组合恰好就是设计模式里模板方法模式Template Method Pattern的基础。所谓模板方法就是把一个业务流程的骨架写在普通方法里把流程中会变化的步骤作为抽象方法留给子类。文章开头那个支付例子就是一个标准模板方法processPay()是模板底下的三个方法都是可变步骤。这样设计的好处是业务层面的逻辑只有一份不会因为子类实现不同而产生分叉子类只需要关注差异化细节即可。public abstract class DataExporter { // 模板方法定义了数据导出的流程骨架 public final boolean export(String filePath) { String data loadData(); String transformed transform(data); return writeFile(filePath, transformed); } // 抽象方法不同数据源加载方式不同 protected abstract String loadData(); // 普通方法默认做一次clean数据 protected String transform(String data) { return data.trim().replaceAll(\\s, ); } // 普通方法统一的文件写入逻辑 private boolean writeFile(String path, String content) { System.out.println(向 path 写入数据 content); return true; } }看到区别了吗loadData()是抽象方法用它的子类可能是从数据库查、从文件读、从远程接口拉完全无法统一。但transform()是一个普通方法大部分情况下的默认清洗逻辑够用个别子类如果需求特殊重写它就行。writeFile()的写入动作大家都一样设计成private连重写的机会都不给。模板方法模式在实际开发里使用频率极高。凡是遇到流程相同但步骤各有差异的场景优先就应该想到用抽象类模板方法去建模。这比到处复制粘贴流程代码健康太多了。4. 抽象类与接口开发中到底该怎么选如果说抽象类本身是初级问题那抽象类和接口怎么选就是中高级问题了。这个选择题几乎每次技术讨论都会出现而且随着JDK版本演进答案一直在变化。4.1 语法之外is-a和can-do的区别从语义上讲抽象类表达的是is-a的关系子类是父类的一个特殊品种且两者在业务模型上有明确的亲缘关系。比如Dog是Animal的一种WechatPayService是一种AbstractPayService。这种关系强调静态的、本质的、血缘上的归属。接口表达的则是can-do的能力契约某个类实现了接口意味着它承诺具备某些能力但它不承诺和接口有任何血缘关系。Flyable接口可以被鸟实现也可以被飞机实现、被超人实现这些类型之间毫无继承关系只共享会飞这个能力点。实际代码里如果你要描述这个类本质上是什么用抽象类如果你要描述这个类能做什么用接口。这条标准听起来简单但很管用。4.2 JDK版本演进让边界变模糊以前面试官最爱问的一句话是抽象类和接口的区别标准答案里有很重要的一条是接口不能有方法实现抽象类可以有。但Java 8之后接口支持default方法这条区别就失效了。Java 8还允许接口里定义static方法Java 9进一步允许接口有private方法。到了今天从纯语法角度说抽象类能做的事接口基本都能做两者最大的语法差异只剩下接口可以多实现implements A, B抽象类只能单继承extends一个。抽象类可以有实例字段、构造方法、受保护成员接口里的字段默认是public static final常量没有构造方法。抽象类里方法可以带各种修饰符接口里方法默认public abstract即使省略也会被补上。所以现在面试如果再问区别聪明人应该回答语法上的差异在缩小但设计意图上的差异仍然鲜明——抽象类描述它是什么接口描述它能做什么。4.3 一个能落地的选型判断流程不少读者看完理论还是不知道怎么选。我给你一个我实际工作中一直用的判断流程照着走基本不会错先看会不会出现同一个行为的不同实现版本。如果不会压根不需要抽象类或接口普通类就行。再看有没有多个不相关的类共享同一套行为。有定义接口。再看这些相关类是否还有大量公共代码可以复用。有考虑抽象类。最后看将来是否可能做多继承扩展。Java的类只能继承一个如果你的设计里某个子类可能需要同时具备多个本质身份那就得用接口来弥补单继承的局限。举一个很典型的例子。你要设计一个飞行器系统里面有直升机、无人机、滑翔机。它们都是飞行器所以你能定义abstract class Aircraft放共用字段比如maxAltitude放共用的动力系统初始化逻辑再把startEngine()做成抽象方法。但如果想描述可以自动驾驶你会定义一个AutopilotCapable接口而只有部分飞机实现它。这时候抽象类和接口的角色就分开了——Aircraft回答它是什么AutopilotCapable回答它能不能。判断维度选抽象类选接口关系类型is-a血缘关系can-do能力契约代码复用子类有大量公共字段/方法各实现类之间没有共享代码多继承需求无需多继承需要实现多种能力演进稳定性继承关系相对固定能力可以任意组合典型场景模板方法模式、基础骨架类回调接口、策略模式、插件机制需要强调一点抽象类里的字段、构造器、protected成员意味着它带状态而接口通常不带状态只带行为约定。如果这个抽象概念本身需要维护状态比如支付订单、数据库连接抽象类更合适如果只是约定一组操作接口更轻量。轻量意味着易测试、易替换、易组合这也是Spring这类框架里到处都是接口的原因之一。5. 实战中的踩坑记录从编译错误到设计复盘最后这部分我分享一下在真实项目里遇到过的坑全是编译和运行时代码留下的血泪教训。5.1 构造器陷阱抽象类构造方法的神秘调用链有一个线上告警曾让我排查了整整一个下午。背景是项目里有个AbstractMessageHandler抽象类它在构造方法里注册了一些监听器public abstract class AbstractMessageHandler { private String handlerName; public AbstractMessageHandler() { this.handlerName this.resolveHandlerName(); System.out.println(注册handler handlerName); } protected abstract String resolveHandlerName(); }子类实现public class OrderMessageHandler extends AbstractMessageHandler { private String name order-handler; Override protected String resolveHandlerName() { return name; } }运行结果是handlerName输出null。原因我在第2.3节提到的构造方法调用链里埋着——父类构造方法先于子类构造方法执行而resolveHandlerName()方法里访问的name字段在父类构造方法执行时还没被赋值。子类的字段初始化语句要等到子类构造方法阶段才执行但super()调用在前面所以子类字段是默认值null。这种抽象方法在构造方法里被调用的坑极其隐蔽因为编译完全通过运行也不报错就是输出结果诡异。正确的修正方案有两个要么在子类里把字段初始化提前到声明处并直接返回常量避免读取实例字段要么在父类构造方法里干脆不要调用抽象方法改成延迟到首次使用时再初始化。5.2 向下转型与抽象类型引用用抽象类型引用子类对象是多态的常规操作但它也带来了一个隐蔽问题——你想调子类独有方法时必须向下转型而转型失败会抛ClassCastException。AbstractPayService service new WechatPayService(); // 编译报错AbstractPayService没有refund方法 service.refund(order123);这时候你得强转if (service instanceof WechatPayService) { WechatPayService wechatService (WechatPayService) service; wechatService.refund(order123); }这里我要特别提醒抽象类引用并判断类型时instanceof永远要放在强转之前。Java 16之后如果你用instanceof模式匹配写法可以在判断的同时完成转型代码更整洁。另外频繁用instanceof去区分具体子类通常是设计信号——说明抽象类里的抽象方法定义得不够全面你绕过多态去处理分支了。更好的做法是在抽象父类里补充一个抽象方法或一个默认实现让调用方不用关心具体子类类型。5.3 别为了规范而滥用抽象类最后一个坑可能很多人都踩过看了设计模式的书觉得抽象类是好的设计于是什么类都想给它套一层抽象父类美其名曰面向抽象编程。结果就是抽象类里只放了一个抽象方法剩下的全是空壳子类之间没有任何公共代码抽象父类本身也没有任何设计约束力。抽象类的真正价值来自于有公共部分可以复用 有变化部分需要约束两件事同时成立。如果只有一个抽象方法而没有公共代码你该用接口如果只有公共代码而没有需要子类差异化实现的方法你该用普通类继承如果两者都没你压根不该引入这个层级。设计时请放下高级感多想想你写的每一层类型到底承担了什么职责而不是图一个看起来架构很好的虚名。注意判断一个抽象类设计是否合理有个简单的自检方法——问自己删掉这个抽象类把公共代码搬到一个工具类或基类里会不会损失什么如果损失的是对子类的强制约束力那这个抽象类有存在价值如果损失为零那这个抽象类就是多余的。这些年做过的项目里凡是抽象类用得好的地方几乎都有一个共性它们的抽象方法数量通常不超过三个且每个都对应业务中真正会变化的维度。抽象类不是越多越好也不是越复杂越好它是用来固化不变、开放变化的工具。拿捏住这个分寸你就能写出既灵活又稳当的代码。