Java 中抽象类定义抽象行为规范

抽象类通过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() 就不合适——肉食动物不适用，违背“所有子类必须实现”的前提
• 真正需要差异化的行为才抽象；共性行为尽量用具体方法实现