接口和抽象类不是语法层面的区别，而是设计思想的不同。语法差异只是表象，真正决定选型的是它们各自解决的工程问题和承载的设计原则。

1 设计层面的根本分歧

抽象类和接口在设计上回答的是两个不同的问题：

  • 抽象类回答的是"哪些逻辑是所有子类共有的，哪些细节需要留给子类"。它的核心诉求是复用共性代码、管控核心流程。
  • 接口回答的是"模块之间应该依赖什么契约来交互"。它的核心诉求是定义行为契约、解耦模块依赖。

这种定位差异决定了它们在扩展方式、变更成本和适用场景上的根本不同：

维度抽象类接口
设计目标封装不变的核心逻辑，开放可变的细节定义行为契约，解耦能力定义与具体实现
关系语义is-a：AlipayPayment 是 AbstractPaymentcan-do：AlipayPayment 能 Payment
扩展维度单继承，垂直扩展多实现，水平扩展
变更成本父类修改影响所有子类接口修改影响所有实现类，成本更高
核心原则模板方法模式、里氏替换原则依赖倒置原则、接口隔离原则、开闭原则

理解这个根本分歧之后，再来看各自的设计细节就比较清晰了。

2 抽象类：流程管控与代码复用

抽象类的核心设计价值是封装不变，开放可变。它定义了一个业务流程的骨架，把固定的、通用的逻辑封装在具体方法中，把需要子类定制的细节声明为抽象方法，同时保证核心流程不被篡改。

这本质上是模板方法模式的实现。

2.1 模板方法的典型结构

以电商支付流程为例。所有支付方式都需要经历"验签 - 参数校验 - 执行支付 - 记录日志"这几个步骤，其中验签、校验和日志是通用逻辑，只有"执行支付"这一步因支付方式而异。

public abstract class AbstractOrderPayment {

    /**
     * 模板方法：用 final 保护，禁止子类篡改核心流程
     */
    public final void pay(OrderDTO order) {
        verifySign(order);
        validateParams(order);
        doPay(order);       // 可变步骤，留给子类实现
        logPayment(order);
    }

    private void verifySign(OrderDTO order) {
        // 通用签名验证，所有支付方式共用
    }

    private void validateParams(OrderDTO order) {
        if (order.getAmount() <= 0) {
            throw new IllegalArgumentException("订单金额非法");
        }
    }

    private void logPayment(OrderDTO order) {
        // 统一格式的支付日志
    }

    /** 子类必须实现的支付逻辑 */
    protected abstract void doPay(OrderDTO order);
}

这里的设计要点有三个：

  1. final 修饰模板方法：这是抽象类管控流程的关键手段。子类可以定制 doPay() 的实现，但无法改变"先验签、再校验、再支付、最后记日志"的执行顺序。
  2. 通用逻辑用 private 封装：验签、校验、日志这些方法不开放给子类，避免被误改。只有可变部分以 protected abstract 的形式暴露。
  3. 子类只关注差异化逻辑：无需重复编写通用代码，符合 DRY 原则。

子类实现非常简洁：

public class AlipayPayment extends AbstractOrderPayment {
    @Override
    protected void doPay(OrderDTO order) {
        // 调用支付宝 SDK 完成支付
    }
}

public class WechatPayment extends AbstractOrderPayment {
    @Override
    protected void doPay(OrderDTO order) {
        // 调用微信支付 SDK 完成支付
    }
}

每个子类只需要实现一个方法，核心流程由父类保证。新增一种支付方式时，通用逻辑的修改只需改父类一处。

2.2 抽象类的设计边界

抽象类并不适合所有场景，它的有效性建立在几个前提之上：

  • 确实存在可复用的具体逻辑。如果抽象类中全是抽象方法、没有任何具体实现，说明没有复用需求，应该用接口。
  • 继承层次不宜过深。超过三层的继承链会导致理解和维护成本急剧上升。此时应转向"接口 + 组合"。
  • 核心流程需要被保护。如果不存在"流程被篡改"的风险，final 模板方法的价值就体现不出来。
  • 状态字段应谨慎使用。抽象类中的状态字段会增加子类间的耦合，状态优先通过方法参数传递或使用组合模式。

3 接口：行为契约与模块解耦

接口的核心设计价值是定义契约，解耦实现。它只规定"做什么"，不关心"怎么做"，是面向接口编程和依赖倒置原则的落地载体。

3.1 依赖倒置与接口隔离

接口解决的核心问题是模块间的耦合。以支付系统为例，如果 OrderService 直接依赖 AlipayPayment 类，那么切换到微信支付时就必须修改 OrderService 的代码。引入 Payment 接口后，OrderService 只依赖接口，具体支付实现可以任意替换：

public interface Payment {
    PaymentResult pay(OrderDTO order);
}

public interface Refundable {
    RefundResult refund(OrderDTO order);
}

这里将"支付"和"退款"拆成两个独立接口，是接口隔离原则的体现——不是所有支付方式都支持退款，把它们塞进同一个接口会导致实现类被迫实现不需要的方法。

3.2 接口在调用端的价值

接口的真正威力体现在调用端。OrderService 依赖 Payment 接口而非具体实现类：

public class OrderService {
    private final Payment payment;

    public OrderService(Payment payment) {
        this.payment = payment;
    }

    public void processOrder(OrderDTO order) {
        PaymentResult result = payment.pay(order);
        // 处理支付结果
    }
}

这段代码的关键在于：替换支付方式不需要修改 OrderService 的任何代码，只需在构造时注入不同的 Payment 实现。新增银联支付，只需创建 UnionPayPayment 类实现 Payment 接口，完全符合开闭原则。

同时，这种设计让单元测试变得简单——可以注入 Mock 对象，无需依赖真实的支付 SDK。

3.3 接口的设计约束

接口一旦发布就应该保持稳定。新增方法会导致所有实现类编译报错，这在大型项目中代价极高。如果需要扩展能力，应该新增接口（如 Refundable）而非修改已有接口。

Java 8 引入的 default 方法在一定程度上缓解了这个约束——可以向接口添加方法而不破坏现有实现。但 default 方法不能替代抽象类，因为它无法持有状态字段、无法定义构造方法、也无法用 final 保护流程不被覆盖。

4 接口与抽象类的组合使用

实际项目中，接口和抽象类往往配合使用。接口定义契约，抽象类封装通用实现，具体类只关注差异化逻辑。这种分层结构同时获得了"解耦"和"复用"两个优势。

// 接口定义契约
public interface Payment {
    PaymentResult pay(OrderDTO order);
}

// 抽象类封装通用逻辑
public abstract class AbstractPaymentTemplate implements Payment {

    protected void validate(OrderDTO order) {
        if (order == null || order.getAmount() <= 0) {
            throw new IllegalArgumentException("订单参数非法");
        }
    }

    @Override
    public PaymentResult pay(OrderDTO order) {
        validate(order);
        PaymentResult result = doPay(order);
        log(order, result);
        return result;
    }

    private void log(OrderDTO order, PaymentResult result) {
        // 统一日志格式
    }

    protected abstract PaymentResult doPay(OrderDTO order);
}

// 具体实现只关注差异化逻辑
public class AlipayPayment extends AbstractPaymentTemplate {
    @Override
    protected PaymentResult doPay(OrderDTO order) {
        // 支付宝专属逻辑
        return new PaymentResult("SUCCESS", "支付宝支付成功");
    }
}

// 微信支付同时实现支付和退款（多能力扩展）
public class WechatPayment extends AbstractPaymentTemplate implements Refundable {
    @Override
    protected PaymentResult doPay(OrderDTO order) {
        return new PaymentResult("SUCCESS", "微信支付成功");
    }

    @Override
    public RefundResult refund(OrderDTO order) {
        return new RefundResult("SUCCESS", "微信退款成功");
    }
}

WechatPayment 通过实现多个接口获得多种能力，不受单继承限制。这是接口在扩展维度上的核心优势。

这种分层结构的调用链路如下：

flowchart TB
    Client["调用方<br/>OrderService"] -->|依赖| IF["Payment 接口<br/>定义契约"]
    IF -->|实现| ABS["AbstractPaymentTemplate<br/>封装通用逻辑"]
    ABS -->|继承| A["AlipayPayment"]
    ABS -->|继承| W["WechatPayment"]
    W -->|额外实现| R["Refundable 接口"]

    style Client fill:#e8f4f8,stroke:#2196F3
    style IF fill:#f3e5f5,stroke:#9C27B0
    style ABS fill:#fff3e0,stroke:#FF9800
    style A fill:#e8f5e9,stroke:#4CAF50
    style W fill:#e8f5e9,stroke:#4CAF50
    style R fill:#f3e5f5,stroke:#9C27B0

5 子类实现的设计约束

不管继承抽象类还是实现接口，子类设计都要遵循几条核心原则，否则容易导致继承体系混乱。

5.1 里氏替换原则

子类必须完全符合父类或接口的契约，不能破坏原有语义。接口约定 pay() 返回 PaymentResult，子类就不应该返回 null；抽象类约定"支付前必须验签"，子类就不应该跳过验签步骤。

// 违反：返回 null，破坏契约
public class BadPayment implements Payment {
    @Override
    public PaymentResult pay(OrderDTO order) {
        return null;
    }
}

// 符合：返回有效的 PaymentResult
public class GoodPayment implements Payment {
    @Override
    public PaymentResult pay(OrderDTO order) {
        return new PaymentResult("SUCCESS", "支付成功");
    }
}

5.2 单一职责原则

子类的核心方法只负责实现父类或接口定义的能力，不夹带无关逻辑。AlipayPayment.doPay() 里如果同时做了库存扣减和订单推送，这些本应属于 InventoryService 和 OrderPushService 的职责就不应该出现在支付类中。正确做法是通过组合引入这些服务。

5.3 组合优于继承

当继承层次过深时（比如 AbstractPayment → AbstractOnlinePayment → AbstractAlipayPayment → AlipayV2Payment），维护成本会显著增加。此时用"接口 + 组合"替代多层继承：

public class AlipayV2Payment implements Payment {

    private final PaymentValidator validator = new PaymentValidator();
    private final PaymentLogger logger = new PaymentLogger();

    @Override
    public PaymentResult pay(OrderDTO order) {
        validator.validate(order);
        // 支付宝 V2 专属逻辑
        logger.log(order);
        return new PaymentResult("SUCCESS", "支付宝V2支付成功");
    }
}

校验和日志逻辑通过组合复用，而非继承。类的层次变浅了，各组件也可以独立演进和测试。

6 设计决策与常见误区

6.1 选型决策

选型的核心判断依据是当前场景要解决什么问题：

flowchart TD
    A["需要定义行为契约？"] -->|是| B["需要复用代码或管控流程？"]
    A -->|否| C["需要控制核心流程？"]
    B -->|是| D["接口 + 抽象类组合"]
    B -->|否| E["接口"]
    C -->|是| F["抽象类"]
    C -->|否| G["普通类"]

几个典型场景的选型参考：

  • 框架基础模板（如 Spring 的 AbstractBeanFactory、JdbcTemplate）：核心流程固定且有大量通用逻辑，选抽象类。
  • 跨模块交互契约（如微服务 API、策略模式）：需要解耦模块依赖，选接口。
  • 支付、退款等多能力扩展：需要多实现且不受单继承限制，选接口或接口组合。
  • JDK 中的 InputStream：封装了通用读取逻辑，read() 由子类实现，是抽象类的典型案例。
  • JDK 中的 Comparator：只定义比较行为契约，无需代码复用，是接口的典型案例。
  • JDK 中的 Collection + AbstractCollection：接口定义契约，抽象类封装通用遍历逻辑，是两者组合的典型案例。

6.2 常见误区

误区一：抽象类中全是抽象方法。 如果没有任何可复用的具体逻辑，说明不存在复用需求，应该用接口而非抽象类。抽象类的价值在于"有东西可以封装"。

误区二：接口当常量池。 只放 public static final 常量、不定义任何方法的接口，违背了接口"定义行为契约"的设计初衷。常量应该用枚举或常量类。

误区三：为只有一个实现的类定义接口。 如果 UserService 只有一个 UserServiceImpl，且没有多态替换或 Mock 测试的需求，接口就是多余的抽象层。按需设计，未来需要时再提取接口也不迟。

误区四：接口臃肿化。 一个接口包含支付、退款、分账、对账等不相关方法，违反接口隔离原则。应该按业务能力拆分为多个接口。

误区五：过度设计。 为了"未来可能的需求"提前定义大量接口和抽象类。简单优先——能用普通类解决的问题不要引入抽象层，发现重复代码时再考虑抽象。

7 总结

接口和抽象类不是对立的，而是互补的。理解它们的设计本质，关键在于把握各自解决的核心问题：

  • 抽象类解决的是"流程管控 + 代码复用"问题。适用于核心流程固定、细节可变的场景，通过 final 方法保护流程、通过 protected abstract 开放扩展点。体现 is-a 的继承关系。
  • 接口解决的是"契约定义 + 模块解耦"问题。适用于定义行为规范、跨模块交互、多能力扩展的场景。体现 can-do 的能力关系。
  • 组合使用是实际项目中最常见的模式：接口定义契约，抽象类封装通用实现，具体类关注差异化逻辑。
  • 子类设计必须遵循里氏替换、单一职责和开闭原则，继承层次过深时转向"接口 + 组合"。

选型不需要提前过度规划。按需设计，在发现重复代码或耦合问题时再引入抽象，比提前铺设一堆接口和抽象类更务实。