3.接口vs抽象类比较

杨充
10 阅读15分钟

3.接口vs抽象类比较

目录介绍
#章节主题关键案例关键图表
01面向对象设计思想范式之别双 11 雪崩订单系统网状 vs 线性流程图
02面向对象的特性封装/抽象/继承/多态钱包余额对不上排查vtable 内存布局图
03接口vs抽象类比较何时选哪个日志器 47 次改动复盘决策树、模板时序图
04接口而非实现编程依赖抽象不依赖具体云迁移 6 万行连锁修改三步重构演化图
05多用组合和少继承继承陷阱与组合优雅企鹅会飞继承翻车类爆炸 vs 正交组合
06设计原则全景图SOLID + 23 模式8000 行上帝类失控SOLID 关系图
07SOLID 原则案例汇 ⭐SOLID 在战场上团队三年 SOLID 之争滥用现场扫描图
08反模式与坏味道 ⭐30+ 嗅觉清单PR 被驳回 17 次坏味道地图
09重构十二式实战12 个最常用手法1200 行结算函数救援重构节奏循环
10可测试性设计 ⭐OOP 的硬验收95% 覆盖率上线即崩测试金字塔
11DDD 与战术建模 ⭐从代码到业务需求文档 70% 失真限界上下文图
12综合实战图片框架 ⭐完整系统实现图片处理系统实战完整架构图

1.先回答上篇思考题

1.1 上篇遗留三道题

上一篇 02.面向对象的特性 末尾留下了三道题：

  • 🟢 Wallet#isAllowed 改成 private 会怎么样？
  • 🟡 信用账户用继承还是用组合？
  • 🔴 流水要事务性写入数据库，抽象层应该如何演化？

本篇要回答的是中题和难题：

题本篇答案
🟢private 后子类不能重写，抽象点被锁死，信用/冻结账户都无从演化
🟡 本篇答说明什么是子类型，信用钱包 is-a 钱包 → 抽象类；只是另一种規则 → 接口 / 策略组合
🔴 本篇答抽象出 TxPipeline，骨架由抽象类提供（模板），动作如「持久化」「发事件」由接口可插拔

三道题同时指向本篇的核心重点：抽象类与接口到底要怎么选？

1.2 日志器被改了47次

让这个问题从抽象变成血肉，来看一段真实代码史。某中台项目 MyLogger.java 的 git 记录：

2021-04-12  init: 创建 MyLogger工具类
2021-05-03  feat: 支持写文件
2021-06-09  feat: 支持写 Kafka，代码中出现第一个 if(type=="kafka")
2021-08-21  feat: 支持写 ES，出现第二个 if
2022-01-14  fix: ES 限流逻辑现在影响了文件写入
2022-03-30  feat: 多租户隔离
2022-09-11  fix: 多租户下限流错乱
...                  ...
2024-02-07  refactor: 拆分为 Logger 接口 + 抽象类，第47个commit

3 年服务商仅增加了 3 个，代码却被改了 47 次。最后一次提交备注是「这是最后一次重构」，你看出问题了吗？

flowchart LR
    A[一开始在<br/>工具类里加 if-else] --加一种--> B[为了复用调为抽象类]
    B --发现调用方被锁死--> C[重构为接口]
    C --发现限流/模板代码重复--> D[接口+抽象类双层]
    D -.主动设计就能避免.-> E[从第一天就该如此]

这反映出一个深刻事实：99% 的技术重构都是「被迫重构」，而不是「主动选型」。本篇要让你从第一天就能选对。

1.3 五次反转排查

重构中间，项目组并不是一路平顺。我们还原出五次"是抽象类还是接口"的反反复复：

反转 1：主张抽象类 → 发现 KafkaLogger 还要 extends KafkaProducer，Java 单继承锁死。

反转 2：改接口 → 发现限流、错误重试、日志头拼装，每个实现三份重复代码。

反转 3：加 default 方法 → 发现限流需要实例状态存 token bucket，接口不能存字段。

反转 4：妥协为"包含一个 RateLimiter 字段的抖动抽象类" → 发现调用方只能看到 extends，失去了接口的多重可组合性。

反转 5：最终落定为双层，「对外 Logger 接口（能力契约） + 对内 AbstractLogger 抽象类（骨架复用）」。

最后这个"双层"方案，正是 Spring、Netty、Mybatis等一线框架的默认取舍。

1.4 灵魂五连问

Q1 ── 接口和抽象类本质上是同一类东西吗？
       └─→ §04 二者深度对比
Q2 ── 为什么 Java 只能单继承却可以多实现？
       └─→ §02 / §03 设计意图
Q3 ── default 方法出现后，接口是不是能取代抽象类？
       └─→ §03.5 default 方法的边界
Q4 ── 「什么时候选哪个」有没有一个不诡辩的补丁？
       └─→ §05 决策树
Q5 ── 为什么主流框架都选「接口+抽象类」双层？
       └─→ §05.3 / §07 综合实战

2.从一个困惑切入

2.1 日志器的烦恼

继上一篇的电商系统。我们要给系统加一个日志组件，要支持：

  • 写文件
  • 写消息队列（kafka）
  • 写远程 ES

所有日志器都要做几件相同的事：判断日志级别是否启用、组装消息头、限流。而具体"写到哪里"则各不相同。

2.2 两种方案对比

flowchart LR
    subgraph 方案A-抽象类
        A1[Logger 抽象类]
        A1 -->|继承| A2[FileLogger]
        A1 -->|继承| A3[KafkaLogger]
        A1 -.提供.-> A4[公共方法 log/限流]
        A1 -.强制.-> A5[抽象方法 doWrite]
    end
    subgraph 方案B-接口
        B1[Logger 接口]
        B1 -->|实现| B2[FileLogger]
        B1 -->|实现| B3[KafkaLogger]
        B1 -.只声明.-> B4[log/doWrite]
    end

方案 A 用抽象类，有公共代码可复用； 方案 B 用接口，只定义契约，无任何复用。

哪个更好？答案不是"哪个更高级"，而是取决于你想解决什么问题。

2.3 抽象的本质

抽象的根本动作：从具体细节中抽离共性。

  • 抽象类抽离的是 "是什么 + 共同行为实现"，is-a 关系；
  • 接口抽离的是 "能做什么"，has-a / can-do 关系。

记住这两个关系词，后面所有差异都从此推导。

3.抽象类详解

3.1 语法定义

public abstract class Logger {
    private String name;
    private Level minLevel;

    public Logger(String name, Level minLevel) {
        this.name = name; this.minLevel = minLevel;
    }

    // 模板方法：固定流程，复用给所有子类
    public final void log(Level level, String msg) {
        if (level.intValue() < minLevel.intValue()) return;
        doWrite(level, msg);   // 留给子类去实现
    }

    // 抽象方法：必须由子类实现
    protected abstract void doWrite(Level level, String msg);
}

public class FileLogger extends Logger {
    @Override
    protected void doWrite(Level level, String msg) {
        // 写文件
    }
}

3.2 三大特点

1. 不能 new（强制被继承）
2. 可以包含字段、可以包含已实现方法
3. 子类必须实现所有抽象方法

3.3 解决的问题

抽象类同时给你两件武器：

flowchart LR
    抽象类 --> 复用[代码复用<br/>共有逻辑写一次]
    抽象类 --> 强制[强制约定<br/>抽象方法必须实现]

如果用普通父类 + 空 log() 方法：

  • 子类忘记重写也不会报错，bug 在运行时才暴露；
  • 父类可以被 new 出来，增加误用风险。

抽象类正是为了堵住这两个口子。

3.4 模板模式

抽象类天然适合模板方法模式：

固定算法骨架（基类的 final 方法）
   └─ 可变步骤（abstract 方法，子类填空）

sequenceDiagram
    participant C as 调用者
    participant L as Logger
    participant F as FileLogger
    C->>L: log(level, msg)
    L->>L: 校验级别
    L->>F: doWrite(level, msg)
    F-->>L: 写完
    L-->>C: 返回

调用方只看到 log，子类只关心 doWrite，双方都不用关心对方。

3.5 模拟实现

Python 没有 abstract 关键字？也能模拟：

class Logger:
    def __init__(self):
        if type(self) is Logger:
            raise TypeError("不能直接实例化")
    def do_write(self, level, msg):
        raise NotImplementedError("子类必须实现 do_write")

通过构造函数禁止实例化 + 方法抛 NotImplementedError，实现等价的语义保护。

4.接口详解

4.1 语法定义

回到日志器。§3 用抽象类给了「is-a」的答案，FileLogger is-a Logger。但如果需求不是"一类东西"，而是"一个可插拔的能力"呢？比如：输出目的地本身应该是可替换的，文件、Kafka、ES 之间没有 is-a 关系，只是都能「追加日志」。

这就要用接口定义「can-do」契约：

public interface LogAppender {
    void append(LogEntry entry);
}

public class FileAppender  implements LogAppender { /* 写文件 */ }
public class KafkaAppender implements LogAppender { /* 写 Kafka */ }
public class ESAppender    implements LogAppender { /* 写 ES */ }

对照 §3 的抽象类 Logger（侧重复用骨架），这里的接口 LogAppender（侧重能力契约）。同一个 Logger 主题，两种抽象工具，解决两个不同的问题。

4.2 三大特点

1. 不能有实例字段（Java 8 前不能有方法体）
2. 只声明契约，不提供实现
3. 类可以实现多个接口（突破单继承限制）

4.3 解决的问题

接口的核心价值是 解耦，不是复用：

public class Logger {
    private List<LogAppender> appenders;   // 只依赖接口，不关心是文件还是 Kafka
    public void log(Level level, String msg) {
        LogEntry entry = new LogEntry(level, msg);
        for (LogAppender a : appenders) a.append(entry);
    }
}
  • 新增一种输出（如写 Redis）→ 只加新类，Logger 零修改；
  • 测试时可以注入假 LogAppender（写到内存，断言输出内容）；
  • 不同输出目的地各自演进，互不踩脚。

4.4 标记接口

有一类接口什么方法都不声明（如 Cloneable、Serializable），称为 Marker Interface。它们的唯一作用是贴标签，通知编译器/运行时"这个类具有某种能力"。

4.5 默认方法

Java 8 起，接口可以有 default 方法：

public interface Comparator<T> {
    int compare(T a, T b);
    default Comparator<T> reversed() { return (a, b) -> compare(b, a); }
}

这是为了接口演化，给老接口加方法时不破坏已有实现。但要警惕：默认方法不应承担"代码复用"职责，那是抽象类的活。

5.两者深度对比

5.1 语法层差异

维度抽象类接口
字段任意仅 static final
方法实现可有Java 8+ 限默认方法
构造器有无
子类关键字extendsimplements
多重继承单多

5.2 设计层差异

flowchart TB
    subgraph 抽象类
        A1[抽离共性<br/>提供模板] --> A2[is-a 关系]
        A2 --> A3[侧重复用]
    end
    subgraph 接口
        B1[定义契约<br/>规约行为] --> B2[has-a / can-do]
        B2 --> B3[侧重解耦]
    end

5.3 关系建模差异

关系选择例子
is-a（本质相同）抽象类FileLogger is-a Logger
can-do（具备能力）接口Bird can-do Fly
like-a（外观相似）接口List like-a Iterable

5.4 演化路径差异

抽象类：自下而上，先有重复子类，再抽公因式上提；

接口：自上而下，先定义协议，再让任何愿意遵守的类实现。

抽象类设计：发现 FileLogger 与 KafkaLogger 都要做"级别校验" → 提到父类
接口设计：先约定"凡是日志器，必须 doWrite()" → 谁愿意做日志器谁实现

6.如何选择

6.1 决策树

flowchart TD
    Start[需要抽象一组类] --> Q1{是 is-a 关系吗}
    Q1 -->|是| Q2{有共同代码可复用吗}
    Q1 -->|否| Q3{需要多重继承能力吗}
    Q2 -->|是| AbsClass[选抽象类]
    Q2 -->|否| Iface1[选接口]
    Q3 -->|是| Iface2[选接口]
    Q3 -->|否| Q4{未来可能换实现吗}
    Q4 -->|是| Iface3[选接口]
    Q4 -->|否| Direct[直接用具体类]

6.2 实战场景

场景推荐理由
日志骨架（限流/级别校验）抽象类公共流程复用，子类只填 doWrite
日志输出目的地（文件/Kafka/ES）接口can-do 能力，多种实现并存
支付渠道（支付宝/微信/银联）接口+抽象类接口定义契约，抽象类提供校验/重试/记账骨架
Wallet 的持久化（MySQL/Redis/内存）接口仅约束行为，底层随意换
实体基类 id/createTime 字段抽象类共享状态字段

6.3 组合使用

实际项目里两者经常搭配出场：

// 接口定义协议
public interface PaymentGateway {
    PayResult pay(Order order);
}

// 抽象类提供公共骨架
public abstract class AbstractGateway implements PaymentGateway {
    @Override
    public final PayResult pay(Order order) {
        validate(order);
        log(order);
        PayResult r = doPay(order);
        notify(r);
        return r;
    }
    protected abstract PayResult doPay(Order order);
}

// 具体实现只填空
public class AlipayGateway   extends AbstractPaymentGateway {
    @Override protected PayResult doPay(Order order) { /* 调支付宝 */ }
}

接口给契约，抽象类给骨架，具体类给特殊性，这是企业级框架的经典三层。

7.总结与延伸

维度抽象类接口
关系is-ahas-a / can-do
主要价值复用解耦
设计方向自下而上自上而下
适用场景同源类的共同骨架跨类型的能力契约

但选好了"用接口还是抽象类"还不够。更重要的是：调用方应该依赖接口，而不是具体实现，这是软件设计中最常被引用、也最常被违反的一条原则。

下一篇 04.接口而非实现编程 会用图片存储与支付渠道两个真实案例，详细拆解这条原则的应用与边界。

8.综合实战案例

延续主线，02 篇我们造了 Wallet，本篇要为"从钱包出发"的支付网关选对抽象。

8.1 支付网关接需求

PM 需求清单：

1. 接入 支付宝 / 微信支付 / 银联
2. 每一家都要走这些公共步骤：
   参数校验 → 限流 → 财务检查 → 发起调用 → 重试 → 记账 → 发领域事件
3. 只有"调用第三方"这一步不同
4. 后期要接跨境支付（PayPal/Stripe）

8.2 纯接口方案的坎

第一版：

public interface PaymentGateway {
    PayResult pay(Order order);
}
public class AlipayGateway   implements PaymentGateway { /* 200 行 */ }
public class WechatPayGateway implements PaymentGateway { /* 195 行 */ }
public class UnionPayGateway  implements PaymentGateway { /* 210 行 */ }

问题马上油漆未干就浮现：

现象本质
三个类的参数校验代码 90% 一样公共骨架未提炼
限流改了一次，三个类都要同步重复代码
新加「财务检查」微服务调用 → 三个类一起改修改辐爹过大
面试新人接个 Stripe 要五天新手不知道公共逻辑不能漏

8.3 抽象类提炼模板

提炼出骨架：

public abstract class AbstractPaymentGateway implements PaymentGateway {
    @Override
    public final PayResult pay(Order order) {        // final 锁住骨架
        validate(order);
        rateLimit();
        finCheck(order);
        PayResult r = retry(() -> doPay(order));     // 唯一可插拔
        record(order, r);
        publish(new PaidEvent(order, r));
        return r;
    }
    protected abstract PayResult doPay(Order order);  // 子类只填"差异那一点"
    // validate / rateLimit / finCheck / retry / record / publish
    // 都是抽象类里的 final 公共方法
}
public class AlipayGateway   extends AbstractPaymentGateway {
    @Override protected PayResult doPay(Order order) { /* 30 行 · 调支付宝 */ }
}
public class WechatPayGateway extends AbstractPaymentGateway {
    @Override protected PayResult doPay(Order order) { /* 28 行 · 调微信支付 */ }
}
public class UnionPayGateway  extends AbstractPaymentGateway {
    @Override protected PayResult doPay(Order order) { /* 32 行 · 调银联 */ }
}

三个子类加起来不到 100 行，而骨架里的公共逻辑（校验/限流/记账/重试/事件）一处都没重复。

代码量从三个类各 ~200 行（600 行）→ 一个骨架 ~160 行 + 三个 doPay ~90 行（250 行）。

但问题远未结束。

8.4 接口+抽象类双层

三个跟进需求让"纯抽象类"也坌了：

  1. 需求 A：理财产品也要「支付」，但他们不走财务检查也不限流。
  2. 需求 B：测试环境需要一个 MockGateway 手动返回返回值。
  3. 需求 C：跨境支付需要 extends ThirdPartySdkBase，Java 单继承少不了。

三件事同时发生，如果只有抽象类这一条路，你要么拆出三棵抽象类树，要么让 SDK Wrapper 变成抽象类重复逯复用。两者都是坑。

最终代码是"接口 × 抽象类"的两层：

// 能力层：什么是"可被调用去支付的东西"
public interface PaymentGateway {
    PayResult pay(Order order);
}

// 骨架层：「企业级标准的骨架」
public abstract class AbstractStandardGateway implements PaymentGateway { ... }

// 骨架层：「跨境供应商的骨架（必须 extends ThirdPartySdkBase）」
public abstract class AbstractCrossBorderGateway extends ThirdPartySdkBase
    implements PaymentGateway { ... }

// 插拔层
public class MockGateway       implements PaymentGateway { ... }   // 测试用
public class AlipayGateway     extends AbstractStandardGateway { ... }
public class StripeGateway     extends AbstractCrossBorderGateway { ... }
public class WealthGateway     extends AbstractStandardGateway { @Override protected boolean needFinCheck() { return false; } }

到这里你会发现：接口与抽象类从来不是二选一，而是"面向不同读者"。

接口写给「调用方」看：你能打什么交道。抽象类写给「实现者」看：你要填什么空。

8.5 类图与时序图

classDiagram
    class PaymentGateway {
        <<interface>>
        +pay(Order) PayResult
    }
    class AbstractStandardGateway {
        <<abstract>>
        +pay(order) final
        #doPay(order)*
        #needFinCheck() bool
    }
    class AbstractCrossBorderGateway {
        <<abstract>>
    }
    PaymentGateway <|.. AbstractStandardGateway
    PaymentGateway <|.. AbstractCrossBorderGateway
    PaymentGateway <|.. MockGateway
    AbstractStandardGateway <|-- AlipayGateway
    AbstractStandardGateway <|-- WechatPayGateway
    AbstractStandardGateway <|-- WealthGateway
    AbstractCrossBorderGateway <|-- StripeGateway

sequenceDiagram
    participant C as 订单服务
    participant G as PaymentGateway(接口)
    participant A as AbstractStandardGateway
    participant S as AlipayGateway
    C->>G: pay(order)
    G->>A: 虚表分发
    A->>A: validate / rateLimit / finCheck
    A->>S: doPay(order)
    S-->>A: PayResult
    A->>A: record / publish
    A-->>C: PayResult

8.6 留下三道思考题

答案在第 04 篇开头揭晓。

🟢 易：AbstractStandardGateway.pay(...) 用了 final。为什么不可以不加 final？不加会出什么事？

🟡 中：现在 needFinCheck() 是抽象类里的一个可重写方法。如果改为「多插拔」（限流/财务检查/重试都可插拔），你会怎么设计？抽象类还够不够用？

🔴 难：跨境支付商不仅要 extends ThirdPartySdkBase，还要遵守 PCI-DSS 合规（每个调用都需走合规检查器）。这件事怎么加进去？它是横切关注点，、应该走接口、抽象类、还是其他处理？

9.认知跃迁总结

回到开篇 47 次重构的日志器。它从一开始就应该是「接口 + 抽象类」双层，但这件事你能只看书学会吗？不能。它需要你亲手别扭五次，每一次反转都会让你对"接口 vs 抽象类"的认知加深一层。

一句话：接口回答「能干什么」，抽象类回答「如何干」。两者不是二选一，是两个不同问题的答案。

下一篇 04.接口而非实现编程，你这里已经学会了「该怎么设计抽象」，但还有一个更哲学的问题：调用方为什么要看接口而不是实现？下篇就从一次【云迁移 6 万行代码】的虐漆事故说起。

avatar
文章
阅读
粉丝