抽象类与接口的区别

抽象类和接口是 Java 面向对象设计的两大核心抽象机制。随着 JDK 8 引入 default 方法、JDK 9 引入 private 方法、JDK 17 引入 sealed 接口，两者的边界在语法层面越来越模糊——但它们的设计意图始终不同。理解这个区别，是做好 OOP 设计决策的基础。

语法层面的核心对比

先通过一张表建立全局认知：

接下来从语法层面逐一展开。

抽象类：共享状态与行为的基类

抽象类是不能被实例化的类，用 abstract 关键字修饰。它的核心能力是承载状态和部分实现：

public abstract class Animal {
    // 1. 可以有实例变量（状态）
    protected String name;
    protected int age;

    // 2. 可以有构造方法（初始化状态）
    public Animal(String name, int age) {
        this.name = name;
        this.age = age;
    }

    // 3. 可以有抽象方法（强制子类实现）
    public abstract void speak();

    // 4. 可以有具体方法（共享通用逻辑）
    public String getInfo() {
        return name + ", age " + age;
    }
}

注意抽象类的构造方法虽然不能直接调用（因为抽象类不能实例化），但子类通过 super() 调用它来初始化从父类继承的状态。这是抽象类的一个关键特性——接口无法做到。

接口：定义行为契约

接口定义了一组行为规范，任何类都可以通过 implements 来声明自己具备这些能力：

public interface Flyable {
    // 1. 变量隐式为 public static final
    int MAX_ALTITUDE = 10000; // 等价于 public static final int

    // 2. 抽象方法（隐式 public abstract）
    void fly();

    // 3. JDK 8+：default 方法（提供默认实现）
    default void land() {
        System.out.println("Landing safely...");
        descend(); // 可以调用 private 方法
    }

    // 4. JDK 8+：static 方法
    static boolean canFlyAt(int altitude) {
        return altitude <= MAX_ALTITUDE;
    }

    // 5. JDK 9+：private 方法（提取 default 方法的公共逻辑）
    private void descend() {
        System.out.println("Descending...");
    }
}

接口的 default 方法和 private 方法让接口具备了一定的代码复用能力，但与抽象类有一个根本区别：接口不能有实例变量（状态）。default 方法只能依赖接口定义的其他方法和常量，无法访问实现类的字段。

组合使用

Java 的单继承 + 多实现机制，天然支持"一个基类 + 多个能力"的设计：

public class Eagle extends Animal implements Flyable, Swimmable {
    public Eagle(String name, int age) {
        super(name, age); // 调用抽象类的构造方法
    }

    @Override
    public void speak() {
        System.out.println("Screech!");
    }

    @Override
    public void fly() {
        System.out.println(name + " soaring at high altitude");
    }

    @Override
    public void swim() {
        System.out.println(name + " diving into water");
    }
}

设计意图的本质区别

语法差异只是表象，理解两者的设计意图才是关键。

抽象类 = "是什么"（is-a）

抽象类表达的是一种分类学关系——子类是父类的一种特殊类型。

Animal（抽象类）
 ├── Dog
 ├── Cat
 └── Eagle

Dog 是一种 Animal、Cat 是一种 Animal——这就是 is-a 关系。抽象类通过共享状态和通用逻辑来体现这种关系。

接口 = "能做什么"（can-do / has-a-capability）

接口表达的是一种能力契约——类声明自己具备某种能力，与它"是什么"无关。

Flyable（接口）
 ├── Eagle    ← 是 Animal
 ├── Airplane ← 是 Vehicle
 └── Superman ← 是 Person

Eagle、Airplane、Superman 之间没有继承关系，但它们都"能飞"。这种跨类族的行为抽象，只有接口能做到。

比喻：抽象类就像"族谱"——你属于哪个家族，决定了你继承的血统和遗产（状态和行为）。接口就像"资格证"——任何人都可以通过考试（实现方法）来获得"能飞""能游泳"的认证，与你的家族无关。

default 方法深度解析

JDK 8 引入 default 方法是接口演进史上最大的变化，值得深入理解。

引入的动机

JDK 8 要给 Collection 接口（所有集合类的父接口）添加 forEach() 方法来支持 Lambda 表达式。问题是：如果直接给接口新增抽象方法，所有已有的实现类都会编译失败——因为它们没有实现新方法。

在 JDK 8 之前，你只有两个选择，都不好：

1. 不改接口 → 新功能无法统一提供
2. 改接口 → 破坏所有现有实现（包括第三方库）

default 方法是第三条路：给接口方法提供默认实现，现有类不需要改任何代码就能继续编译。

// JDK 8 源码：Iterable 接口
public interface Iterable<T> {
    Iterator<T> iterator();

    // 新增的 default 方法，不破坏任何已有实现
    default void forEach(Consumer<? super T> action) {
        Objects.requireNonNull(action);
        for (T t : this) {
            action.accept(t);
        }
    }

    default Spliterator<T> spliterator() {
        return Spliterators.spliteratorUnknownSize(iterator(), 0);
    }
}

菱形继承冲突

当一个类实现了两个接口，这两个接口有相同签名的 default 方法时，编译器不知道该用哪个——这叫菱形继承问题（Diamond Problem）。

interface A {
    default void hello() {
        System.out.println("Hello from A");
    }
}

interface B {
    default void hello() {
        System.out.println("Hello from B");
    }
}

class C implements A, B {
    // 编译错误！必须显式解决冲突
    @Override
    public void hello() {
        // 方案 1：自己实现
        System.out.println("Hello from C");

        // 方案 2：选择某个接口的默认实现
        A.super.hello();  // 调用 A 的 default 方法
    }
}

冲突解决的优先级规则：

1. 类优先：如果父类提供了具体方法，接口的 default 方法被忽略
2. 最具体的接口优先：如果 B extends A，且两者都有同名 default 方法，B 的优先
3. 多个接口冲突：编译器报错，必须手动解决

interface A {
    default void hello() { System.out.println("A"); }
}
interface B extends A {
    default void hello() { System.out.println("B"); }
}
class D implements A, B {
    // 不需要重写——B 比 A 更具体，自动使用 B 的实现
}

default 方法的局限性

default 方法看起来让接口和抽象类更像了，但有一个根本限制：default 方法不能直接访问实现类的实例变量。

interface Greeting {
    // ❌ 无法做到：接口里没有 name 字段
    // default void greet() { System.out.println("Hi, " + name); }

    // ✅ 只能通过方法间接获取
    String getName();
    default void greet() {
        System.out.println("Hi, " + getName());
    }
}

这就是接口和抽象类的根本分野：抽象类可以定义和管理状态，接口不行。

JDK 版本演进全景

接口的能力随 JDK 版本不断增强，了解这个演进路径有助于理解"为什么"：

JDK 9：private 方法

多个 default 方法之间经常有重复逻辑。JDK 9 之前，你只能把公共逻辑提取为另一个 default 方法，但这个方法会暴露在接口的公共 API 中。private 方法解决了这个问题：

public interface Logging {
    default void logInfo(String msg) {
        log("INFO", msg);
    }

    default void logError(String msg) {
        log("ERROR", msg);
    }

    // JDK 9+：提取公共逻辑，不暴露在公共 API 中
    private void log(String level, String msg) {
        System.out.println("[" + level + "] " + msg);
    }
}

JDK 17：sealed 接口

sealed 关键字让接口可以限制哪些类可以实现它：

public sealed interface Shape
    permits Circle, Rectangle, Triangle {
    double area();
}

// 只有这三个类可以实现 Shape
public final class Circle implements Shape { ... }
public final class Rectangle implements Shape { ... }
public final class Triangle implements Shape { ... }

sealed 接口配合 switch 模式匹配，编译器可以确认你处理了所有可能的实现类型（穷举检查），不需要 default 分支：

// JDK 21+ switch 模式匹配
double getArea(Shape shape) {
    return switch (shape) {
        case Circle c    -> Math.PI * c.radius() * c.radius();
        case Rectangle r -> r.width() * r.height();
        case Triangle t  -> 0.5 * t.base() * t.height();
        // 不需要 default，编译器已知所有可能的类型
    };
}

设计模式中的应用

抽象类和接口在设计模式中各有对应的经典用法。

模板方法模式 → 抽象类

模板方法模式用抽象类定义算法骨架，把可变步骤留给子类实现：

public abstract class DataImporter {
    // 模板方法：定义固定的算法步骤
    public final void importData() {
        String raw = readData();      // 步骤 1：读取数据（子类实现）
        Object parsed = parse(raw);   // 步骤 2：解析数据（子类实现）
        validate(parsed);             // 步骤 3：校验（通用逻辑）
        save(parsed);                 // 步骤 4：保存（通用逻辑）
    }

    protected abstract String readData();
    protected abstract Object parse(String raw);

    protected void validate(Object data) { /* 通用校验逻辑 */ }
    protected void save(Object data) { /* 通用保存逻辑 */ }
}

// 子类只需实现可变的部分
public class CsvImporter extends DataImporter {
    @Override protected String readData() { return readCsvFile(); }
    @Override protected Object parse(String raw) { return parseCsv(raw); }
}

关键点：模板方法用 final 修饰防止被覆写，算法骨架不可变；protected abstract 方法是"钩子"，由子类填充。

策略模式 → 接口

策略模式用接口定义一族算法，通过组合而非继承来切换行为：

// 策略接口
public interface SortStrategy {
    void sort(int[] array);
}

// 不同策略的实现
public class QuickSort implements SortStrategy {
    @Override public void sort(int[] array) { /* 快排 */ }
}
public class MergeSort implements SortStrategy {
    @Override public void sort(int[] array) { /* 归并排序 */ }
}

// 使用策略的上下文
public class Sorter {
    private SortStrategy strategy;

    public void setStrategy(SortStrategy strategy) {
        this.strategy = strategy;
    }

    public void performSort(int[] array) {
        strategy.sort(array);
    }
}

JDK 8 之后，简单的策略可以直接用 Lambda 表达式替代：

Sorter sorter = new Sorter();
sorter.setStrategy(array -> Arrays.sort(array)); // Lambda 替代实现类

实际开发中的选择决策

在实际工程架构开发中都会遇到"什么时候用抽象类，什么时候用接口"的问题。核心决策树如下：

需要定义额外的状态（成员变量）吗？
├── 是 → 抽象类
└── 否 → 需要被多个不相关的类实现吗？
      ├── 是 → 接口
      └── 否 → 需要控制实现范围吗？
            ├── 是 → sealed 接口
            └── 否 → 两者皆可，优先接口（更灵活）

一句话原则：优先用接口定义行为，只在需要共享状态或提供大量通用实现时才用抽象类。

字节码层面的差异

从 JVM 的角度看，抽象类和接口在字节码中被不同的指令调用：

• 抽象类的方法：通过 invokevirtual 调用（虚方法分派，基于类的继承链查找）
• 接口的方法：通过 invokeinterface 调用（接口方法分派，需要额外的类型检查）

在 HotSpot JVM 中，invokeinterface 比 invokevirtual 稍慢，因为接口方法的分派表（itable）比虚方法表（vtable）多了一次间接查找。但在现代 JVM 的 JIT 优化下（如内联缓存），这个差异几乎可以忽略不计。

总结

记住一个根本性的区别：抽象类管理的是"遗产"（继承来的状态和行为），接口定义的是"契约"（承诺能做的事情）。 当你纠结选哪个时，问自己：我需要传递状态，还是定义能力？答案就清楚了。