抽象类通过abstract方法定义子类必须实现的核心契约，可同时封装共性逻辑；抽象方法无实现、不可私有/静态/最终，子类须全部重写或自身声明为抽象类。
Java 中抽象类定义抽象行为的规范，核心在于用 abstract 方法 建立子类必须遵守的契约，而不是提供具体实现。
抽象方法必须声明在抽象类中
只要类里有一个方法被 abstract 修饰（无方法体、以分号结尾），这个类就必须用 abstract class 声明。反过来，抽象类可以没有抽象方法，但一旦有抽象方法，就强制要求子类响应。
- 语法上：抽象方法只有签名，比如
public abstract double area(); - 不能是
private、final或static—— 因为它要被子类可见、可重写、可继承 - 抽象方法不带
{}，也不能有方法体，否则编译报错
子类必须实现全部抽象方法（除非自身也是抽象类）
非抽象子类继承抽象类后，必须用 @Override 显式重写所有抽象方法，并给出具体逻辑。这是 Java 编译器强制执行的“行为一致性”保障。
- 如果子类没实现某个抽象方法，编译直接失败
- 若子类不想立即实现，可也声明为
abstract class，把实现责任留给更下层子类 - 实现时方法签名（返回类型、名称、参数列表）必须完全一致，访问权限不能更严格（如父类是
public，子类不能写protected）
抽象行为与共性实现可共存于同一类
抽象类不是“纯接口”，它既能定义抽象行为（规范），也能封装可复用的具体逻辑（如通用校验、日志、初始化等），让子类“按规矩做事”同时“少写重复代码”。
立即学习“Java免费学习笔记（深入）”；
- 例如：
Shape抽象类定义abstract double area()，同时提供public void printInfo() { System.out.println("Area: " + area()); } - 子类只需专注实现
area()，就能直接用printInfo()，无需再写格式化输出逻辑 - 这种组合使抽象类比接口更侧重“模板+约束”，而不仅是“能力声明”
抽象行为的设计应聚焦领域本质契约
抽象方法不是随便加的，它应代表该类体系中所有子类**必然具备、但实现各异**的核心能力。设计时需回归业务语义，避免过度抽象或粒度太细。
- 比如
Animal类中定义abstract void makeSound()合理，因为每种动物都会发声，只是方式不同 - 但定义
abstract void eatGrass()就不合适——肉食动物不适用，违背“所有子类必须实现”的前提 - 真正需要差异化的行为才抽象；共性行为尽量用具体方法实现
