Java接口和抽象类有什么区别？结合场景理解怎么选

在 Java 中，接口和抽象类都可以描述一类对象“能做什么”，也都能参与多态。但它们表达的设计意图不同：接口主要定义可由不同类型共同实现的能力或契约；抽象类则适合为一组紧密相关的类提供共同身份、状态和部分实现。

选择时不必先背规则，可以先问两个问题：这些类型是否应当属于同一个继承体系？它们是否需要共享实例状态或构造过程？前者往往指向抽象类，后者通常也更适合抽象类；如果只是希望不同类型遵守同一套操作约定，接口通常更合适。

先看一段可运行示例

下面的代码展示了一个常见组合：Payable 表示能力，Employee 表示相关对象的共同基类。一个类可以继承一个类，同时实现多个接口。

interface Payable {
    double calculatePay();
}

abstract class Employee {
    private final String name;

    protected Employee(String name) {
        if (name == null || name.isBlank()) {
            throw new IllegalArgumentException("name must not be blank");
        }
        this.name = name;
    }

    public String getName() {
        return name;
    }

    public abstract String role();
}

class SalariedEmployee extends Employee implements Payable {
    private final double monthlySalary;

    SalariedEmployee(String name, double monthlySalary) {
        super(name);
        if (monthlySalary < 0) {
            throw new IllegalArgumentException("salary must not be negative");
        }
        this.monthlySalary = monthlySalary;
    }

    @Override
    public double calculatePay() {
        return monthlySalary;
    }

    @Override
    public String role() {
        return "salaried";
    }
}

class Contractor implements Payable {
    private final double hours;
    private final double hourlyRate;

    Contractor(double hours, double hourlyRate) {
        this.hours = hours;
        this.hourlyRate = hourlyRate;
    }

    @Override
    public double calculatePay() {
        return hours * hourlyRate;
    }
}

public class Main {
    public static void main(String[] args) {
        Employee employee = new SalariedEmployee("Lin", 8000);
        Payable[] payees = {
            (Payable) employee,
            new Contractor(10, 200)
        };

        System.out.println(employee.getName() + ": " + employee.role());
        for (Payable payee : payees) {
            System.out.println(payee.calculatePay());
        }
    }
}

将代码保存为 Main.java，使用 JDK 17 编译和运行：

javac Main.java
java Main

示例中的雇员共享姓名和角色约定，因此用抽象类保存共同状态，并要求子类实现 role()。承包方并不是雇员，但也能计算报酬，因此它只实现 Payable。这正是两者配合使用的典型方式。

核心区别：共享实现，还是定义契约

接口能做什么，不能做什么

接口字段不是对象状态

接口中声明的字段隐含为 public static final，必须在声明时初始化。因此它们属于接口类型本身的常量，不是每个实现对象各自保存的实例字段。

interface Limits {
    int MAX_RETRIES = 3;
}

// 等价于：
// public static final int MAX_RETRIES = 3;

接口不适合保存每个对象的可变状态，例如订单当前金额、连接状态或用户姓名。把这类数据放到接口字段中不仅做不到实例隔离，也容易造成所有实现共享常量的误解。需要对象状态时，应放在实现类或合适的抽象类中。

接口方法有多种形式

不带方法体的接口实例方法隐含为 public abstract。实现类必须提供实现，除非实现类本身也是抽象类。

Java 8 引入默认方法和静态方法。默认方法有方法体，供实现类继承，也允许实现类覆盖；静态方法属于接口本身，通常通过接口名调用，不会作为可覆盖的实例方法继承给实现类。Java 9 起，接口还可以用私有实例方法或私有静态方法复用接口内部代码；这些方法不能被实现类当作公共能力调用。

interface Auditable {
    void audit(String action);

    default void auditCreated() {
        audit("created");
    }

    static boolean isValidAction(String action) {
        return action != null && !action.isBlank();
    }

    private void internalHelper() {
        // 仅供本接口中的方法复用
    }
}

上例中的私有方法从 Java 9 开始可用。如果项目要运行在更早版本的 JDK 上，就不能使用它。接口默认方法也不是“给所有实现类添加可变状态”的办法：它没有实例字段可供保存状态，适合共享不依赖接口实例字段的通用行为。

实现多个接口时要留意默认方法冲突

一个类可以实现多个接口，这让接口适合表达可以组合的能力。不过，若两个接口提供同签名的默认方法，类必须明确选择或编写自己的实现；不能把决定留给编译器。

interface First {
    default String label() {
        return "first";
    }
}

interface Second {
    default String label() {
        return "second";
    }
}

class Combined implements First, Second {
    @Override
    public String label() {
        return First.super.label();
    }
}

如果类的父类已经提供了具体实例方法，该方法优先于接口的默认方法。设计默认方法时，应避免不必要地占用常见方法名，并考虑现有实现类是否可能因此出现冲突。

抽象类能做什么，不能做什么

它可以保存状态并控制初始化

抽象类可以有实例字段、构造器、静态成员、具体方法和抽象方法。构造器不能直接用来创建抽象类对象，但创建子类对象时会按构造链执行，常用于检查或初始化所有子类都需要的数据。

abstract class Document {
    private final String id;

    protected Document(String id) {
        if (id == null || id.isBlank()) {
            throw new IllegalArgumentException("id must not be blank");
        }
        this.id = id;
    }

    public String id() {
        return id;
    }

    public abstract String render();
}

子类必须调用父类构造器，满足基类初始化要求。这里的字段和构造逻辑都是抽象类相对于接口的重要能力。

抽象类不一定包含抽象方法

一个类可以没有任何抽象方法，但仍声明为 abstract，以禁止直接创建该类对象，或表达它是某个继承体系的共同基类。反过来，只要类包含未实现的抽象方法，它就必须声明为抽象类。

抽象类可以实现接口而不实现接口的全部抽象方法，此时它必须保持抽象；具体子类再补齐实现。抽象类也能提供接口方法的部分或全部实现。

抽象方法有约束

抽象方法没有方法体，也不能同时声明为 private、static 或 final：私有方法不可被子类实现，静态方法不参与实例方法的覆盖，最终方法又禁止覆盖。抽象方法的可见性还决定了子类是否有资格实现它，不能把包级抽象方法当作跨包扩展点。

抽象类本身不能再声明为 final，因为 final 类不允许被继承，而抽象类要求通过子类完成或扩展其抽象契约。

结合场景选择

选择接口：关注“能做什么”

当几个类型之间没有明显的共同父类，却需要被同一段代码调用时，优先考虑接口。例如 Payable 可以同时由雇员、供应商或承包方实现；可关闭的资源可以由文件、连接等不同类型实现；可排序、可比较等能力也适合以接口表达。

面向接口编程还便于替换实现。业务代码依赖接口，就可以在不改调用方主要逻辑的情况下换成真实实现、测试替身或另一种实现。但这并不意味着所有类都要抽一个只有一个实现的接口：如果没有替换、组合或边界隔离的需要，额外接口可能只是增加跳转和维护成本。

接口也适合公开稳定的扩展点，让第三方实现自己的类型。需要注意的是，接口属于 API 契约：给已发布接口增加新的抽象方法，会使已有实现类在重新编译时需要补上实现，也可能在运行时遇到缺少实现的问题。默认方法有时能缓和演进问题，但不是万能兼容方案，仍需评估默认行为是否对所有实现都正确，以及是否会与其他接口发生冲突。

选择抽象类：存在稳定的共同身份或实现

如果一组类具有稳定的“是什么”关系，并共享有意义的状态、构造规则或受控流程，抽象类通常更合适。例如多个消息处理器都要保存配置、验证输入，再调用子类实现的处理步骤；或者一类领域对象共享标识和生命周期规则。

抽象类可以把不希望子类改变的流程集中实现，并开放少量抽象方法或受保护的扩展钩子。这类设计常被称为模板方法模式。不过，基类一旦承担太多职责，子类就可能被迫继承并不需要的状态和行为。因此，共享代码应当确实属于同一个概念模型，而不是为了减少几行重复代码就建立继承关系。

两者结合：一个表达身份，多个表达能力

Java 类只能继承一个类，却可以实现多个接口。因此常见设计是让抽象类承担共同身份和状态，让接口表达可组合能力。前面的示例中，SalariedEmployee 继承 Employee，并实现 Payable；Contractor 不继承 Employee，但仍可被当作 Payable 使用。

如果一个类既需要继承已有的父类，又要参与某种统一调用协议，接口尤其有用。反过来，若两个类型唯一的共同点只是“都能调用某方法”，通常没有必要强行把其中一个设为另一个的父类。

容易混淆的边界与常见错误

不要把接口理解为“只能有抽象方法”

这是过时的简化说法。现代 Java 接口可以有默认方法和静态方法，Java 9 起还可以有私有方法。但接口仍不能拥有普通实例字段，也不能声明构造器。判断适不适合接口，关键不是“有没有方法体”，而是它描述的是独立契约还是带状态的共同基类。

不要只为了复用代码就滥用抽象类

不同领域对象偶然有相同算法，不代表它们应当建立继承关系。直接继承会把子类绑定到父类的 API、初始化规则和变化节奏。若只是复用独立功能，可以考虑组合、委托或普通工具类；如果是可互换的行为契约，用接口表达往往更清楚。

不要把接口常量当作配置存储

接口字段是公共静态常量，不适合放运行时配置、可修改参数或某个实例独有的数据。用接口堆放无关常量也会模糊接口的用途。常量应归属于真正拥有其语义的类型，配置数据则应通过配置对象或其他合适机制传递。

不要认为声明接口就获得安全隔离

接口可以限制某段代码在编译期依赖的操作面，也能帮助组织模块边界，但它不是沙箱，也不是授权机制。调用方仍可能通过其他引用访问实现对象的公开方法；运行时类型检查、反射、模块配置和进程隔离也各有边界。不能因为对象实现了某个“安全接口”，就假定其实现可信或敏感操作已受到保护。权限校验和输入验证必须放在真正执行操作的边界上。

不要把参数数量误当成接口与抽象类的区别

接口和抽象类不会各自设定一套不同的参数上限。Java 方法参数受语言和虚拟机对方法描述符的限制；按 JVM 规范，参数槽位计数上限为 255，实例方法还要把隐含的 this 计入这一限制，long 和 double 各占两个槽位。编译器也会检查对应的限制。这个上限不是建议值：方法参数多到难以理解时，通常应考虑把相关数据组织成参数对象，而不是追求接近上限。

参数数量限制与安全性也不是一回事。减少参数或使用接口类型，不会自动防止恶意输入、越权操作或资源滥用；是否需要校验，取决于数据从哪里来、操作边界在哪里以及系统的威胁模型。

一个实用的选择流程

1. 先看关系：类型是否真的是同一类事物的不同细分？如果是，再评估抽象类是否能合理承载共同身份。
2. 再看状态：是否需要每个对象各自保存字段、执行共同构造检查？如果需要，抽象类或组合通常比接口更合适。
3. 再看组合：能力是否可能由互不相关的类型共同具备？如果是，用接口描述能力。
4. 再看继承约束：实现类是否可能已经继承其他类？若需要横向扩展能力，接口不会占用它唯一的类继承位置。
5. 最后看演进：这是内部实现还是对外发布的 API？对外契约需要考虑已有实现、默认方法冲突和版本兼容。

简化成一句话：共享状态、构造规则和稳定的“是什么”关系，优先考虑抽象类；可由不同类型组合实现的“能做什么”，优先考虑接口。两者并不互斥，合理的设计常常是抽象类提供共同基础、接口刻画外部能力。最终判断标准不是代码能不能编译，而是继承关系是否真实、契约是否清晰，以及后续变化是否容易控制。