抽象类不必含抽象方法，其核心是限制实例化并允许部分实现；适用场景包括共享状态、构造逻辑及非public成员；设计时应明确扩展点，避免泛型擦除导致的覆写失败。
抽象类必须有抽象方法吗？
不是。Java 中的 abstract class 可以完全不包含 abstract 方法，只要类声明了 abstract 修饰符，它就不能被实例化。这种设计常用于“禁止直接创建对象，但又想提供默认实现”的场景。
常见误判是认为抽象类 = 必须定义未实现方法。实际上，它的核心语义是「限制实例化 + 允许部分实现」。
- 纯模板类：只提供
protected工具方法和字段，子类通过super()复用逻辑 - 框架基类：如 Spring 的
AbstractController，封装了请求生命周期钩子，但本身不强制子类重写任何方法 - 避免错误使用：如果类没有抽象方法，又没提供任何可复用逻辑，那它大概率不该是抽象类——考虑用普通类 +
private构造器更合适
什么时候该用 abstract class 而不是 interface？
当需要共享状态（字段）、提供构造逻辑、或定义非 public 成员时，abstract class 是唯一选择。interface 在 Java 8+ 支持 default 和 static 方法，但仍有硬性限制：
- interface 不能有实例字段（
public static final常量除外） - interface 不能定义构造器，无法控制子类初始化顺序
- interface 中的
default方法无法访问实现类的私有成员，而抽象类的protected方法可以 - 如果已有类继承了其他父类，只能实现 interface；若需复用行为，就得靠抽象类做中间层（例如
extends AbstractList<T> implements Serializable）
典型例子：java.util.AbstractList 提供了 size()、isEmpty()、iterator() 等基础实现，子类只需实现 get(int) 和 size() 即可运行，这是 interface 无法替代的。
立即学习“Java免费学习笔记（深入）”；
如何设计可维护的抽象类层次？
关键不是“能写多少公共方法”，而是控制扩展点和破坏边界。一个高耦合的抽象类会让子类被迫重写无关逻辑，或因父类变更而意外失效。
实操建议：
- 把真正需要子类定制的行为声明为
protected abstract方法（如doProcess()），而非暴露public abstract - 用模板方法模式封装流程：在
final方法中调用钩子方法，防止子类绕过关键步骤（如execute() { before(); doWork(); after(); }） - 避免在抽象类中依赖具体实现类（如 new 某个子类），这会锁死继承结构
- 字段尽量
protected或final，不要用public字段——子类直接修改会破坏父类不变量
public abstract class DataProcessor<T> {
protected final Logger log = LoggerFactory.getLogger(getClass());
protected final long timeoutMs;
protected DataProcessor(long timeoutMs) {
this.timeoutMs = timeoutMs;
}
public final void run(T input) {
log.info("Starting process for {}", input);
try {
validate(input);
T result = doProcess(input); // 子类实现
onSuccess(result);
} catch (Exception e) {
onError(e);
}
}
protected abstract T doProcess(T input);
protected void validate(T input) {} // 默认空实现，子类可选重写
protected void onSuccess(T result) {}
protected void onError(Exception e) {}
}
抽象类和泛型一起用要注意什么？
泛型抽象类容易在类型擦除后引发子类无法正确覆盖方法的问题。最典型的坑是：子类重写方法时，因类型参数被擦除，导致签名不匹配，变成重载而非重写。
例如：
- 父类声明
abstract <R> R transform(T item)，子类写@Override String transform(String s)—— 实际不会覆盖，因为桥接方法未生成 - 推荐写法：把类型参数上移到类级别（
abstract class Transformer<I, O>），方法签名用具体类型（abstract O transform(I item)），这样子类能明确重写 - 构造器中不要依赖泛型参数做 instanceof 判断，运行时已不可知
- 如果需要运行时类型信息，显式传入
Class<O>参数，而不是靠getClass().getTypeParameters()
泛型抽象类不是语法糖，它是对继承契约的强化。用错一次，调试时看到 MethodNotFoundException 或静默调用父类空实现，就很难快速定位。
