抽象类通过定义抽象方法统一接口、强制子类实现、支撑多态，形成编译期契约；它提供可复用代码与定制边界结合的“半成品模板”，并禁止无意义实例化。
抽象类定义抽象方法，核心意义在于统一接口、强制实现、支撑多态。它不是为了写代码方便，而是为整个继承体系建立清晰的契约。
明确子类必须提供的能力
抽象方法只声明“做什么”，不规定“怎么做”。比如在 Animal 抽象类中定义 public abstract void shout();，就等于告诉所有子类：“你必须能叫，但狗叫‘汪汪’、猫叫‘喵喵’，你自己决定。”这样避免了子类遗漏关键行为，也防止父类强行给出不通用的默认实现。
- 没有抽象方法时，子类可能忘记实现某个共性功能
- 有抽象方法后，编译器会强制检查——不实现就报错
- 这种约束发生在编译期，比运行时报错更早、更安全
为多态提供可依赖的调用入口
抽象方法是多态的基石。因为父类引用可以指向任意子类对象，而调用抽象方法时，实际执行的是子类重写后的版本。例如：
- Animal a1 = new Dog(); a1.shout(); → 输出“汪汪”
- Animal a2 = new Cat(); a2.shout(); → 输出“喵喵”
- 调用方只需面向 Animal 编程，无需知道具体类型
如果没有抽象方法，父类无法保证子类一定有 shout() 这个方法，多态调用就失去依据。
区分“模板”与“规范”的职责
抽象类本身可以包含普通方法（如构造器、工具方法、部分逻辑），也能定义抽象方法。这种混合结构让抽象类既能提供可复用的代码，又能划出不可绕过的实现边界：
- 普通方法：封装子类共用逻辑，比如 getName()、logCreation()
- 抽象方法：标记子类专属逻辑，比如 move()、attack()
- 二者结合，形成“半成品模板”——既减少重复，又保留定制空间
避免无意义的对象实例化
抽象类不能被 new 出来，这本身就是一种设计保护。如果一个类只定义了 shout() 却没说明“谁在叫”，那创建一个 Animal 实例就没有业务含义。抽象方法的存在，直观表明这个类只是概念，真正的行为必须由具体子类落实。
- 哪怕抽象类里没有抽象方法，加 abstract 也能禁止实例化
- 但一旦出现抽象方法，abstract class 就成为必要语法要求
- 这是语言层面对“抽象即不可具象”这一设计意图的直接支持
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
