Java 接口和抽象类有什么区别？有了 default 方法还需要抽象类吗？

知识点详解：一个导出功能，为什么可能同时需要接口和抽象类？

接口先把“使用方需要什么”规定下来

咱们假设项目里需要 PDF 导出、CSV 导出，还有调用远程服务完成的导出。

使用方只关心：传入数据，得到导出结果。它不需要知道 PDF 用什么模板，也不需要知道远程服务的地址。可以把这个能力定义成 Exporter 接口，让调用方依赖同一约定。

这就是接口的价值：不同实现可以有完全不同的内部结构，但使用方仍然按照同一能力调用。一个对象还可以实现多个接口，例如同时具有导出与审计能力，不需要把所有能力都塞进同一父类。

抽象类可以把“一类对象共用的东西”放在一起

PDF 与 CSV 导出器可能都有自己的编码配置、最大行数，并且都需要在导出前检查数据。

抽象基类可以保存这些实例字段，通过构造器要求每个对象在创建时交齐配置，再实现公共校验步骤，把格式相关部分留给子类。

注意，抽象类虽然不能直接 new，却仍然有构造器。创建具体子类对象时，父类初始化过程也需要执行。“不能直接实例化”不等于“不需要初始化”。

default 方法能提供一个默认行为，但接口里的字段本质上是常量，不能给每个导出器分别保存一份可变配置。这个差别没有因为接口能写方法体而消失。

default 解决默认行为，不替代全部继承需求

default 方法适合提供可以被覆盖的默认实现，例如一个能力接口的通用辅助行为。它也可以在演进接口时帮助已有实现继续工作，但仍要检查新增方法是否与已有方法冲突。

如果一个类实现的两个接口都提供同签名、无法直接确定优先级的 default 方法，就需要显式解决冲突。不能把“能实现多个接口”理解成“多个默认实现会自动合并”。

与此对应，抽象类也有成本：子类已经继承了别的类，就不能再继承这一基类。过多共享步骤还可能让本来不同的导出方式被迫遵循同一种流程。

两者一起使用，不代表所有实现都必须继承基类

一种清楚的设计是：PDF 和 CSV 都实现 Exporter，并通过 AbstractExporter 复用适合自己的状态与步骤；远程导出器只实现 Exporter，不继承这个不适合它的本地基类。

这样调用方看见的仍然是同一接口，但实现方没有被绑死。

如果共享的只是一个日志工具或校验服务，也可以通过组合来复用，而不是为了少写几行代码建立父子关系。是否继承，需要判断子类是否真的属于这类对象，以及父类约定会不会限制它。

本文针对 Java 的类型与继承规则，依据 JLS 接口规范 和 Oracle 抽象类教程核验。

面试官继续追问

抽象类一定要有抽象方法吗？

不一定。类被声明为 abstract，就不能直接实例化；它可以没有抽象方法，只是设计上不允许直接创建这个基础类型。

什么时候不适合把公共代码放到父类？

多个类只是碰巧使用同一种工具，但没有稳定的“是一种”关系时，组合通常更直接。还要避免父类修改引起所有子类意外变化。

接口是否只能表示行为，不能返回状态？

接口可以定义读取状态的方法，实现类自己保存状态。不能在接口里声明每个对象独立的实例字段，不代表接口方法不能让使用者获取对象信息。

面试速记卡

• 接口：能力契约，一个类可以实现多个接口。
• 现代接口：可以提供部分方法实现，不只是抽象方法集合。
• 抽象类：可以保存实例状态、执行构造初始化、共享实现。
• 继承限制：一个类只能继承一个类，抽象基类也占用这条关系。
• 组合方案：接口保持契约，抽象类提供可选实现，不强迫所有实现继承。