在Java中接口和抽象类如何选择_Java设计场景对比说明_技术教程

优先用 interface 定义行为契约且无需共享状态或构造逻辑；必须用 abstract class 当需 protected 字段、构造器逻辑或模板方法。Java 8+ default 方法不改变本质差异：接口不能访问实例字段，且单继承多实现的约束不可替代。

什么时候该用 `interface` 而不是 `abstract class`

当需要定义一组行为契约，且不关心实现细节、也不需要共享状态或构造逻辑时，优先选 interface。Java 8+ 支持 default 和 static 方法，但它们不能访问实例字段——这恰恰划清了边界：接口只应描述“能做什么”，而非“怎么存数据”。

常见误用场景：

在 interface 中声明 public static final 常量本无问题，但若开始往里塞配置类式的静态工具方法，说明职责已超界
为复用代码强行把多个无关类拉进同一个 abstract class 继承树，结果导致子类被迫继承一堆用不到的字段和逻辑

典型适用案例：Comparable、Runnable、自定义的 PaymentStrategy —— 它们只约束行为签名，不携带状态。

什么情况下必须用 `abstract class`

当你需要提供可被子类直接复用的非静态字段、带逻辑的构造器、或者部分实现（尤其是涉及模板方法模式）时，abstract class 是唯一选择。

关键判断点：

是否需要定义 protected 字段供子类访问？→ 只能在 abstract class 中做
是否要强制子类走统一初始化流程（比如打开资源 + 校验参数）？→ 抽象类构造器可完成，接口做不到
是否已有类继承链，而新功能需插入共通逻辑？→ 接口无法修改已有继承关系，抽象类可通过重构父类注入

abstract class DataProcessor {
    protected final Logger logger = LoggerFactory.getLogger(getClass());
    protected String source;

    protected DataProcessor(String source) {
        this.source = Objects.requireNonNull(source);
        init(); // 模板方法中的钩子
    }

    protected abstract void init();
    public abstract void process();
}

Java 8+ 后 `default` 方法会不会让接口和抽象类越来越像

不会。表面相似，本质不同：

default 方法不能访问 this 的非静态字段，所有实现仍必须各自维护状态
一个类只能 extends 一个抽象类，但可 implements 多个接口——这是根本性差异，影响架构伸缩性
如果两个接口都提供了同名 default 方法，实现类必须显式覆写，否则编译失败；而抽象类中方法冲突由继承层级自然解决

真实陷阱：有人用 default 方法模拟“轻量级抽象类”，结果在多实现组合时陷入菱形继承歧义，或因无法访问实例状态而反复传参，反而增加耦合。

Spring 或其他框架中常见的误判点

框架常模糊两者边界，容易误导设计决策：

@FunctionalInterface 标记的接口（如 Supplier）绝不能塞进字段或复杂逻辑，哪怕它只含一个抽象方法
Spring 的 @Service 类若同时实现多个接口，这些接口应纯粹表达能力（如 UserReposit ory + Cacheable），而非承担数据模型职责
MyBatis 的 Mapper 接口是纯契约，但开发者有时会试图在其中加 default 方法做缓存封装——这违反了 Mapper 的单一职责，也绕过了 MyBatis 的代理机制