抽象类通过抽象方法强制子类实现统一行为契约，确保编译期约束；抽象方法不能为private、static或final，仅可public/protected；结合模板方法可控制执行流程；相较接口，抽象类更适合含共享状态或逻辑的契约定义。
在 Java 中，通过抽象类定义抽象方法，是强制子类实现统一行为契约最直接、最标准的方式。抽象方法本身没有实现，只声明签名，子类必须重写它——否则编译不通过。这本质上是一种“编译期契约”，确保所有具体子类都提供某项能力的明确实现。
用抽象类 + 抽象方法定义契约
抽象类代表一种“不完整但有共性”的类型，其中的抽象方法就是该类型要求所有子类必须履行的义务。例如：
// 定义一个动物行为契约
abstract class Animal {
public abstract void makeSound();
public abstract int getLegCount();
}
任何继承 Animal 的非抽象子类（如 Dog、Bird）都必须实现 makeSound() 和 getLegCount()，否则无法编译。
抽象方法不能是 private、static 或 final
因为这些修饰符与“强制重写”冲突：
立即学习“Java免费学习笔记（深入）”；
在 Java 中初始化和管理阿里云 SDK客户端。包括单例模式、线程安全、endpoint 与 region 配置、VPC 终端节点、同步与异步等。
- private：子类不可见，根本无法重写；
- static：属于类而非实例，不参与多态，也无法被“重写”（只能隐藏）；
- final：禁止子类修改，和抽象方法的初衷矛盾。
合法的抽象方法只能是 public 或 protected（默认包访问也允许），且不能有方法体（即不能有 {}）。
结合模板方法模式增强契约控制力
光靠抽象方法只能保证“有实现”，但无法约束“怎么调用”。这时可在抽象类中定义 模板方法（普通 final 方法），把流程骨架固定下来，再由抽象方法填充关键步骤：
abstract class DataProcessor {
public final void process() {
validate();
parse();
transform();
save();
}
protected abstract void validate();
protected abstract void parse();
protected abstract void transform();
protected abstract void save();
}
子类无法改变执行顺序，但必须实现每一步逻辑——行为契约从“做什么”延伸到“何时做”。
接口 vs 抽象类：选谁来定义契约？
如果只需定义纯行为规范（无状态、无复用代码），接口更轻量、支持多实现；但若需共享字段、构造逻辑或默认实现（Java 8+），抽象类更合适。注意：
- 接口中的
default或static方法不能强制实现，只有abstract方法（隐式）才有此效果； - 抽象类可同时包含抽象方法、具体方法、字段和构造器，更适合表达“有共同基础的契约族”。
