Java 从入门到精通（六）：抽象类与接口到底怎么选？

Java 从入门到精通（六）：抽象类与接口到底怎么选？

学到继承和多态之后，很多人会马上遇到一个新问题：

抽象类和接口看起来都像是在"定义规范"，那它们到底有什么区别？

更麻烦的是，网上很多解释会把它们讲得很像面试题。

比如：

• 抽象类可以有构造方法

• 接口不能有实例变量

• 一个类只能继承一个抽象类，但可以实现多个接口

这些话都没错，但如果只停在这层，写代码的时候还是会犹豫。

真正重要的问题不是"背出差异"，而是：

什么时候应该用抽象类，什么时候应该用接口？

这篇就把这个问题讲清楚。

一、先别急着记区别，先看它们为什么会出现

当系统开始变复杂之后，你会遇到一种很常见的需求：

有些类之间明显有共同点，但这个共同点又不足以直接变成一个可以实例化的"普通父类"。

比如：

• 动物都会叫、都会移动，但"动物"本身又不一定对应一个具体对象

• 支付方式都能支付，但"支付方式"本身不是一个具体支付渠道

• 日志组件都能输出日志，但你不会直接 new 一个"日志系统基类"来用

这时候就会需要"抽象层"。

而 Java 里最常见的两种抽象层写法，就是：

• 抽象类

• 接口

它们都能表达"规范"，但表达的方向并不完全一样。

二、什么是抽象类？

抽象类本质上是：

一个不能直接实例化、但可以用来承载共性实现和统一约束的父类。

最关键的点有两个：

1. 它本身不能 new

2. 它既可以定义抽象方法，也可以写具体实现

例如：

public abstract class Animal {

    protected String name;



    public Animal(String name) {

        this.name = name;

    }



    public void sleep() {

        System.out.println(name + " 在睡觉");

    }



    public abstract void makeSound();

}

这里的 Animal 就很典型。

它做了三件事：

• 把所有动物都有的名字抽出来

• 把所有动物都可能共享的 sleep() 行为写好

• 把 makeSound() 留给子类自己实现

子类可以这样写：

public class Dog extends Animal {

    public Dog(String name) {

        super(name);

    }



    @Override

    public void makeSound() {

        System.out.println(name + "：汪汪汪");

    }

}

public class Cat extends Animal {

    public Cat(String name) {

        super(name);

    }



    @Override

    public void makeSound() {

        System.out.println(name + "：喵喵喵");

    }

}

这时候抽象类的作用就很明确了：

• 共性放父类

• 差异放子类

• 父类负责建立统一骨架

三、什么是接口？

接口更像一种能力声明。

它表达的重点不是"你是谁"，而是"你能做什么"。

例如：

public interface Flyable {

    void fly();

}

public interface Swimmable {

    void swim();

}

然后不同类按需实现：

public class Bird implements Flyable {

    @Override

    public void fly() {

        System.out.println("鸟在飞");

    }

}

public class Fish implements Swimmable {

    @Override

    public void swim() {

        System.out.println("鱼在游");

    }

}

public class Duck implements Flyable, Swimmable {

    @Override

    public void fly() {

        System.out.println("鸭子会飞");

    }



    @Override

    public void swim() {

        System.out.println("鸭子会游");

    }

}

这里接口表达的不是继承层次，而是能力组合。

所以我更喜欢把接口理解成：

接口是一种行为契约。

谁实现它，谁就承诺提供这组行为。

四、抽象类和接口最核心的区别，不是语法，是建模方向

很多人一上来就对比语法细节，其实容易把重点看偏。

更本质的区别是：

1）抽象类描述的是"是什么"

它更强调继承体系。

比如：

• Dog 是一种 Animal

• Teacher 是一种 Person

• AliPay 可能是一种 PaymentChannel

这类关系通常满足：

is-a

也就是"某个对象本质上属于这个父类体系"。

2）接口描述的是"能做什么"

它更强调行为能力。

比如：

• 这个对象能 Fly

• 这个对象能 Serialize

• 这个对象能 Pay

• 这个对象能 Log

这类关系通常满足：

can-do

也就是"它具备某种能力"。

如果把这层想清楚，很多选择题其实就不难了。

五、什么时候优先用抽象类？

如果你面对的是一组明显有统一父类身份的对象，而且这些对象之间还有不少共享实现，那抽象类通常更合适。

典型场景 1：有稳定的继承层次

例如：

• Person → Student / Teacher

• Animal → Dog / Cat

• PaymentChannel → AliPay / WeChatPay

这类情况里，父类身份很明确。

典型场景 2：子类之间确实有大量公共代码

比如：

• 公共字段

• 公共工具方法

• 通用模板流程

• 默认行为

抽象类适合把这些东西直接沉淀下来。

典型场景 3：你想在父类中控制一部分执行框架

这就是经典的模板方法思想。

例如：

public abstract class ReportGenerator {

    public final void generate() {

        fetchData();

        processData();

        export();

    }



    protected abstract void fetchData();



    protected abstract void processData();



    protected void export() {

        System.out.println("导出报告");

    }

}

这里父类把整体流程定死了，但把局部细节交给子类实现。

这就是抽象类非常典型的用法。

六、什么时候优先用接口？

如果你面对的是一组不一定属于同一个继承体系、但都需要提供某种行为能力的对象，那接口通常更合适。

典型场景 1：你想定义统一能力，而不是统一身份

例如：

• 可支付 Payable

• 可比较 Comparable

• 可运行 Runnable

• 可关闭 AutoCloseable

这些都不是身份，而是能力。

典型场景 2：一个类可能同时具备多种能力

Java 不支持多继承类，但支持实现多个接口。

例如一个对象既能：

• 导出

• 打印

• 序列化

那它很自然就应该由多个接口组合描述。

典型场景 3：你想让系统更容易扩展和解耦

接口最强的地方，是让调用方依赖抽象，而不是依赖具体实现。

例如：

public interface MessageSender {

    void send(String message);

}

然后不同实现分别负责：

• 邮件发送

• 短信发送

• 站内信发送

• 企业微信发送

调用方只依赖 MessageSender，根本不用关心底层是哪个实现类。

这就是接口在业务开发里非常高频的原因。

七、一个业务例子：抽象类和接口怎么一起用

真实系统里，它们往往不是二选一，而是配合使用。

比如做一个支付系统。

第一步：先定义统一父类

public abstract class Payment {

    protected String appId;



    public Payment(String appId) {

        this.appId = appId;

    }



    public void checkConfig() {

        System.out.println("检查支付配置：" + appId);

    }



    public abstract void pay(double amount);

}

这里抽象类承载的是：

• 公共字段

• 公共配置校验逻辑

• 统一的支付入口约束

第二步：再定义附加能力接口

public interface Refundable {

    void refund(double amount);

}

public interface Queryable {

    void queryStatus(String orderId);

}

第三步：具体类组合使用

public class AliPay extends Payment implements Refundable, Queryable {

    public AliPay(String appId) {

        super(appId);

    }



    @Override

    public void pay(double amount) {

        System.out.println("支付宝支付：" + amount);

    }



    @Override

    public void refund(double amount) {

        System.out.println("支付宝退款：" + amount);

    }



    @Override

    public void queryStatus(String orderId) {

        System.out.println("查询支付宝订单状态：" + orderId);

    }

}

这里你会发现：

• 抽象类负责"支付体系里的共性"

• 接口负责"支付之外可组合的能力"

这就是比较自然的设计。

八、Java 8 之后，接口为什么看起来越来越像抽象类？

这是很多人会困惑的一点。

因为从 Java 8 开始，接口可以有 default 方法和 static 方法。

例如：

public interface Loggable {

    void log(String msg);



    default void logInfo(String msg) {

        log("[INFO] " + msg);

    }

}

这会让人觉得：

"那接口不也能写实现了吗？是不是能替代抽象类了？"

答案是：不能完全替代。

因为即使接口能带默认实现，它仍然不适合承担下面这些职责：

• 管理对象状态

• 存放实例字段

• 组织稳定的继承层次

• 承担较重的模板流程骨架

所以 Java 8 之后，接口确实更强了，但它的核心定位仍然是"能力契约"，不是"半个父类"。

九、初学者最容易踩的几个坑

1）觉得接口一定比抽象类高级

不是。

它们是两种不同建模工具，不存在绝对谁更高级。

2）为了复用代码硬上接口

如果你真正需要的是：

• 公共字段

• 公共状态

• 公共默认实现

• 稳定的继承关系

那抽象类通常更自然。

3）为了图省事一切都做成抽象类

如果系统里很多类只是"共享一种能力"，并不属于同一父类体系，那硬塞进抽象类会把模型越做越重。

4）把"接口能有 default 方法"理解成"接口和抽象类没区别了"

还是有区别。

default 方法是为了增强接口扩展能力，不是为了让接口承担完整父类职责。

十、一个实用判断口诀

如果你写代码时总在犹豫，可以先问自己两个问题。

问题 1：我现在是在描述"身份"，还是在描述"能力"？

• 如果是身份，优先想抽象类

• 如果是能力，优先想接口

问题 2：我是否真的需要共享状态和大量默认实现？

• 如果需要，抽象类更自然

• 如果不需要，只是统一行为约束，接口更合适

很多设计问题，到最后其实就是这两个问题。

十一、小结

如果把这篇压缩成几句话，最核心的是：

1. 抽象类更像"半成品父类"，适合表达继承体系里的共性。

2. 接口更像"能力契约"，适合表达可以被不同类复用的行为。

3. 真实项目里，它们往往不是互斥关系，而是一起用。

所以以后再遇到"抽象类和接口怎么选"，别先背语法差异。

先想清楚：

你是在给一组对象定义共同身份，还是在给一组对象定义统一能力。

这个问题想明白了，选择通常就不会太偏。

下一篇

下一篇我准备继续往下写：

Java 从入门到精通（七）：String、StringBuilder 和包装类，哪些地方最容易写出低效代码？