接口都能写默认实现了，为什么还需要抽象类

「Java 进阶之路」系列 Day19

写在前面

JDK 8 之前，接口和抽象类的边界很清楚：接口只能声明方法签名，抽象类才能写具体实现。可 JDK 8 给接口加上了 default 方法之后，接口也能带方法体了------这下不少人会犯嘀咕：接口都能写实现了，那抽象类是不是快没用了？这篇就借 JDK 集合框架的真实设计，把这条边界重新讲清楚。

一、是什么：一个只管契约，一个自带半成品

接口（interface） ：一组方法契约，只声明"能做什么"，不关心内部怎么实现。JDK 8 之前接口里只能有抽象方法和 public static final 常量；JDK 8 允许写 default/static 方法，JDK 9 又加了 private 方法（给 default 方法内部拆分复用逻辑用）。但接口从头到尾都不能有实例字段、不能有构造器，撑不起跨方法共享的可变状态。

抽象类（abstract class） ：不能被 new 出来的类，可以有构造器、实例字段、已经写好实现的具体方法，也可以有留给子类填的抽象方法------本质是一个"没写完的类"。

二、为什么：单继承逼出来的分工

Java 类只能单继承（一个类只能 extends 一个父类），但一个对象常常要同时具备好几种互不相关的"能力标签"，比如 ArrayList 同时实现了 List、RandomAccess、Cloneable、Serializable。这几种能力之间没有共同状态可复用，纯粹是行为契约，所以用接口------一个类可以 implements 任意多个。

反过来，当一批子类之间有大量重复的样板代码、只是某一步骤实现不同，就该用抽象类把公共逻辑收进去，子类只填差异点。这正是模板方法模式 在 JDK 里最常见的应用：AbstractList 帮所有 List 实现类写好了 iterator、indexOf、equals、hashCode，ArrayList/LinkedList 只需要实现 get 和 size 这两个核心方法，就能拿到一整套完整功能。

flowchart TB subgraph s1[能力契约接口] c1[Cloneable 能被克隆] c2[Serializable 能被序列化] end subgraph s2[骨架实现抽象类] al[AbstractList 已写好iterator indexOf equals] arr[ArrayList 只需实现get和size] link[LinkedList 只需实现get和size] al --> arr al --> link end arr --> c1 arr --> c2

一句话区分：接口回答"能做什么"，抽象类回答"是什么"------前者是无状态的行为契约，可以多个一起实现；后者是同一家族共享代码和状态的半成品，只能单继承一个。

三、怎么用：四个最容易踩的坑

坑一：两个接口的同名 default 方法冲突

java 复制代码

interface Flyer {
    default void move() {
        System.out.println("飞起来");
    }
}

interface Swimmer {
    default void move() {
        System.out.println("游起来");
    }
}

class Duck implements Flyer, Swimmer {
    // 不重写这里编译直接报错：两个父接口的 move 冲突，无法确定用哪个
    @Override
    public void move() {
        Flyer.super.move();
        Swimmer.super.move();
    }
}

Java 用"编译期强制报错、必须显式重写"的方式处理这种冲突，不会像 C++ 多重继承那样产生隐式二义性------发现哪里报了这个错，说明确实需要程序员自己决定优先用谁的实现，或者两个都要调用。

也正因为这样，default 方法的设计初衷只是让接口能平滑升级 ------比如 JDK 8 给 Collection 接口新增 stream() 方法时，如果直接加一个抽象方法，所有历史实现类都会编译报错，改成 default 给个默认实现，老代码就完全不用动。它不是让接口变成能攒状态的抽象类，接口里堆太多 default 实现逻辑反而会让"契约"和"实现"混在一起。

坑二：接口里的字段不是普通变量

java 复制代码

interface Config {
    int MAX_RETRY = 3; // 等价于 public static final int MAX_RETRY = 3;
}

接口里写的字段编译器会自动加上 public static final，很多人以为能当普通共享变量改来改去，实际上它是常量，赋值之后不能再变。

坑三：接口加了一堆 default 方法，还算函数式接口吗

java 复制代码

@FunctionalInterface
interface Greeter {
    void greet(String name);   // 唯一的抽象方法，Lambda 就是补上这个方法的实现

    default void greetTwice(String name) {
        greet(name);
        greet(name);
    }
}

Greeter g = name -> System.out.println("你好，" + name);
g.greetTwice("小明");

函数式接口的判定标准是有且仅有一个抽象方法 （SAM，Single Abstract Method），default/static 方法已经自带实现，不需要调用方用 Lambda 补全，所以不计入这个限制。这也是为什么 JDK 里的 Comparator（带 reversed、thenComparing 等 default 方法）、Predicate（带 and、or、negate 等 default 方法，外加 isEqual、not 等 static 方法）依然能直接用 Lambda 创建------它们都只有一个抽象方法。

坑四：抽象类只能单继承，复用多套逻辑该怎么办

抽象类的复用能力被单继承卡死。假设除了 AbstractList 这个"迭代骨架"，项目里还有一个 AuditLogger 类，封装了统一格式记录操作日志的公共逻辑------LoggingList 想同时复用这两份逻辑，但 Java 只允许 extends 一个类：

java 复制代码

class AuditLogger {
    // 公共逻辑：统一格式记录操作日志，供持有者复用
    protected final void audit(String action) {
        System.out.println("[audit] " + action);
    }
}

// LoggingList 本质是一个 List，这个"是什么"的继承名额必须留给 AbstractList
// AuditLogger 的逻辑只能靠组合来复用，Java 不允许再继承第二个父类
class LoggingList extends AbstractList<String> {
    private final List<String> delegate = new ArrayList<>();
    private final AuditLogger logger = new AuditLogger(); // 组合：持有一个实例，而不是继承它

    @Override
    public String get(int index) {
        logger.audit("读取下标 " + index); // 复用AuditLogger的逻辑，走组合而不是继承
        return delegate.get(index);
    }

    @Override
    public int size() {
        return delegate.size();
    }
}

这就是"组合优于继承"的一个实际来源：接口设计上放开了多实现，但类的复用能力被限制在单继承------AbstractList 这个继承名额留给了"是什么"（LoggingList 确实是一个 List），AuditLogger 这份额外的逻辑就只能改成组合，持有它的实例、调用它的方法，而不是硬挤继承链凑一个不伦不类的公共父类。

四、面试追问

Q1：接口和抽象类最核心的区别是什么，怎么选？

接口回答"能做什么"（无状态的能力契约），抽象类回答"是什么"（同一家族、共享代码和字段）。有公共状态、公共实现要复用就用抽象类；只是行为约定、且一个类可能要同时具备多种能力，就用接口。

Q2：JDK 8 之后接口能写 default 方法实现了，是不是就可以取代抽象类？

不能。default 方法的设计目的是让接口能在不破坏历史实现类的前提下平滑新增方法，不是让接口拥有状态。接口依然不能有实例字段、不能有构造器，维护不了跨方法共享的可变数据，这些场景还是必须用抽象类。

Q3：一个类实现的两个接口有同名 default 方法，会发生什么？

编译报错，Java 强制要求实现类显式重写这个方法解决冲突，可以用接口名加 .super.方法名() 分别调用两个父接口的默认实现，不会像 C++ 那样产生隐式的二义性调用。

Q4：抽象类里的抽象方法和接口里的方法本质区别是什么？

语法上都没有方法体，但语义完全不同：抽象类的抽象方法是"这个继承体系内部有一步交给子类填"，服务的是模板方法这种内部实现机制；接口方法是"外部使用者能拿这个类型做什么"的契约，面向的是调用方而不是子类实现者。

Q5：JDK 集合框架里 List 是接口、AbstractList 是抽象类，两者的分工是什么？

List 定义了"是一个有序集合"该有的行为契约，面向所有使用者；AbstractList 是这份契约的骨架实现（模板方法模式），把 iterator、indexOf、equals 等通用逻辑都写好了，ArrayList/LinkedList 继承它之后只需要实现 get/size 这几个核心方法就能拿到完整功能，避免每个实现类都重复写一遍。

Q6：一个接口写了很多个 default 方法，还能是函数式接口吗？

能。函数式接口的判定标准是"有且仅有一个抽象方法"，default/static/private 方法本身已经有实现，不需要调用方通过 Lambda 补全，不计入这个限制。JDK 里的 Comparator、Predicate 虽然带了不少 default/static 辅助方法，依然是标准的函数式接口。

Q7：为什么说"组合优于继承"，这跟接口和抽象类的选择有什么关系？

因为 Java 类只能单继承，一旦某个类想同时复用两个不相关父类提供的逻辑（比如既要继承 AbstractList 拿到迭代骨架，又想复用另一个类的公共逻辑），继承链根本装不下，只能被迫找一个别扭的公共父类把两套逻辑硬拧在一起。更好的做法是把其中一个逻辑改造成组合：持有它的实例、调用它的方法，而不是继承它。这也是为什么接口设计上放开了"多实现"，但类的复用能力被限制在单继承------复用多个不相关的逻辑本来就该用组合，而不是硬挤继承链。

下一篇预告

Day20 讲一个更容易被问倒的细节：为什么重写 equals 一定要重写 hashCode------HashMap、HashSet 这些基于哈希表的容器到底是怎么利用这两个方法定位元素的，不重写会踩什么坑。