Java接口与抽象类的使用方法

优先用interface定义行为契约且无需状态或构造逻辑；需共享字段、构造器或强制初始化流程时用abstract class；判断依据：是否需状态、构造控制、跨无关类复用。

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

当需要定义一组行为契约，且不关心实现细节、也不需要共享状态或构造逻辑时，优先选 interface。Java 8+ 允许 interface 有 default 和 static 方法，但它们不能有实例字段、不能有构造器、不能有 protected 或 private 非静态方法。

• 多个不相关的类想实现同一套能力（比如 Runnable、Comparable），只能靠 interface —— Java 不支持多继承 abstract class
• 需要被 record、enum 或已存在类实现时，只能用 interface
• 若未来可能由不同模块分别实现，且希望解耦编译依赖，interface 的二进制兼容性更好（新增 default 方法通常不破坏实现类）

abstract class 真正不可替代的场景

当你需要提供可复用的骨架代码、共享字段、构造器逻辑，或者强制子类走特定初始化流程时，abstract class 是唯一选择。

• 子类必须共用某些实例变量（如 protected String name;），interface 无法声明非 public static final 字段
• 需要在构造过程中执行校验或资源预分配（比如抽象日志组件要求传入 Logger 实例）
• 已有类层级中，父类已承担部分实现，又需约束下层行为（例如 AbstractList 提供了大部分 List 方法，只留 get(int) 和 size() 抽象）

Java 8+ 后常见的误用陷阱

开发者常因 default 方法的存在，误以为 interface 可以替代 abstract class，但语义和限制完全不同。

• default 方法不能访问实现类的私有字段，也不能调用 this 上的非接口方法，本质上仍是“契约侧”的扩展，不是“继承侧”的复用
• 如果两个 interface 提供了同签名的 default 方法，实现类必须显式重写该方法，否则编译失败 —— 这不是多继承的便利，而是冲突显式化
• abstract class 的子类只能单继承，但可以同时实现多个 interface；反过来，interface 不能 extends 类，只能 extends 其他 interface

一个务实的

判断流程

写新类型前，快速问自己三个问题：

• 是否需要保存状态（字段）？→ 是 → 用 abstract class
• 是否需要控制构造过程（比如参数校验、资源初始化）？→ 是 → 用 abstract class
• 是否预期被完全不相关的类实现（比如 UI 组件和网络请求类都要“可取消”）？→ 是 → 用 interface

如果三个都是“否”，再看是否只是定义常量和纯行为——那 interface 更轻量；如果后续发现要加字段或构造逻辑，就说明当初该选 abstract class。

// 示例：错误地试图在 interface 中存状态
interface BadCounter {
    private int count = 0; // 编译错误！interface 中不能有非 static final 字段
    default void inc() { count++; } // 也无法访问这个 count
}

// 正确做法：用 abstract class 封装可变状态
abstract class Counter {
    protected int count = 0;
    public void inc() { count++; }
    public abstract void reset();
}

真正难的不是语法，是第一次设计时对“谁该负责什么”的判断——一旦把状态或构造逻辑塞进 interface，后面要么改接口（破坏兼容性），要么绕弯子（比如用 ThreadLocal 模拟状态），代价远高于初期多花两分钟想清楚。