Java中的抽象类与接口选择与实现_技术教程

该用 abstract class 而不是 interface 的情况是：需共享代码逻辑、定义部分实现或强制子类继承特定类层级时；因 Java 不支持多继承，一个类只能继承一个抽象类，却可实现多个接口。

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

当需要共享代码逻辑、定义部分实现、或强制子类继承某个类层级时，选 abstract class。Java 不支持多继承，但一个类只能 extends 一个抽象类，却能 implements 多个接口——这是最根本的取舍前提。

常见误用是：为“定义行为”而硬写抽象类，结果导致后续扩展卡死。比如设计日志组件，若已有 BaseLogger 封装了通用格式化、异步写入逻辑，且所有子类都应基于它构建，那就适合抽象类；但如果只是约定“能记录、能关闭”，那 interface Logger 更轻量、更灵活。

abstract class 可含构造器、成员变量（protected 或包级）、静态方法、具体方法（非 default）、甚至 main 方法
接口不能有构造器，字段默认是 pub lic static final，方法默认是 public abstract（Java 8+ 支持 default 和 static，但仍是契约导向）
如果未来可能要加新方法，又不想破坏现有实现，interface 加 default 方法比抽象类加新抽象方法更安全

Java 8+ 接口里 `default` 方法的真实用途

default 方法不是为了替代抽象类，而是为接口演进提供向后兼容能力。它解决的是“老接口加新功能，不强制所有实现类改代码”的问题，不是让你把业务逻辑塞进去。

典型反模式：在接口里写一堆 default 方法，封装完整流程（比如 process() 调用 validate() → transform() → save()），这会让接口失去契约性，也掩盖了真正的职责归属。

只对真正通用、极少被重写的辅助逻辑用 default（如 Collections.sort() 的包装、空集合判空工具逻辑）
避免在 default 方法中调用其他 default 方法形成隐式依赖链
如果 default 方法需访问状态，说明这个行为本该属于具体类或抽象类——接口不该持有状态

抽象类与接口混用的合理场景

真实项目里经常两者并存：抽象类提供骨架实现，接口定义能力契约。例如 Spring 的 AbstractController（抽象类）负责请求生命周期管理，而它同时实现 InitializingBean、DisposableBean（接口）来接入容器生命周期钩子。

这种组合的关键在于分层清晰：抽象类管“怎么做”，接口管“能做什么”。混淆会导致继承树臃肿、语义模糊。

一个类可以 extends AbstractService + implements Serializable, Cloneable —— 前者是实现复用，后两者是能力声明
不要让抽象类去实现多个业务接口（如 extends AbstractUserManager implements OrderProcessor, ReportGenerator），这会让抽象类承担过多正交职责
如果发现抽象类里大量方法只是抛 UnsupportedOperationException，说明它其实该拆成多个接口 + 更小粒度的抽象基类

编译期与运行期差异带来的坑

接口方法调用走的是虚拟机的接口调用指令（invokeinterface），抽象类方法是普通虚方法调用（invokevirtual）。性能差异极小，但反射或字节码操作时行为不同——比如 Method.getDeclaringClass() 对 default 方法返回的是接口类，对抽象类方法返回的是抽象类本身。

更实际的问题是默认方法冲突：当一个类同时实现两个接口，它们都有同签名的 default 方法，编译直接报错，必须在子类中显式覆写。而抽象类不会出现这种“多源默认实现”冲突。

使用 Lombok 的 @EqualsAndHashCode 时，若类实现了带 default 方法的接口，Lombok 不会自动处理接口方法，别指望它帮你生成基于接口契约的相等逻辑
Mockito 3.4.0+ 才支持 mock default 方法，旧版本 mock 接口时这些方法会被忽略，可能导致测试通过但运行时报 UnsupportedOperationException
序列化时，接口不参与，但抽象类的可序列化字段和 readObject 等钩子会生效——这点常被忽略，尤其在 RPC 场景下