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

抽象类通过abstract方法定义子类必须实现的核心契约，同时还能封装一些通用逻辑。抽象方法没有实现体，也不能是private、static或final——这些限制确保了它就是为了被继承和重写而设计的。子类要么全部实现这些抽象方法，要么自己也声明为抽象类，把责任继续往下传。

在Ja va中，抽象类定义抽象行为的规范，重点在于利用abstract方法来建立子类必须遵守的规则，而不是直接提供具体实现。这个机制保证了不同子类在核心行为上的“一致性”，是面向对象设计中“契约式编程”的一种体现。

抽象方法必须声明在抽象类中

只要一个类里出现了被abstract修饰的方法（没有方法体，以分号结尾），这个类就必须用abstract class来声明。反过来看，抽象类可以完全不包含抽象方法，但一旦有了，就等于强制要求子类做出响应。从语法上讲，抽象方法只有签名，比如public abstract double area();，它不能是private、final或static——因为它需要被子类可见、可以重写、可以被继承。抽象方法也不带花括号{}，更不能有方法体，否则编译就会报错。这个“无实现”的设计，正是抽象类的精髓所在。

子类必须实现全部抽象方法（除非自身也是抽象类）

非抽象子类继承抽象类后，必须用@Override显式重写所有抽象方法，并给出具体逻辑。这是Ja va编译器强制执行的一条规则，用来保证行为上的“一致性”。如果子类没有实现某个抽象方法，编译会直接失败。当然，如果子类暂时不想完成实现，也可以声明为abstract class，把实现责任继续留给更下层的子类。需要注意的是，实现时方法签名（返回类型、名称、参数列表）必须完全一致，并且访问权限不能比父类更严格——比如父类方法如果声明为public，子类就不能写成protected。

抽象行为与共性实现可共存于同一类

抽象类并不是一个“纯接口”，它既能定义抽象行为（也就是规范），也能封装可复用的具体逻辑（比如通用的校验、日志记录、初始化代码等）。这让子类既能“按规矩做事”，又能“少写重复代码”。举个例子，Shape抽象类可以定义abstract double area()，同时提供一个public void printInfo() { System.out.println("Area: " + area()); }的具体方法。子类只需要专注实现area()，就能直接使用printInfo()，不必再写格式化输出逻辑。这种“模板+约束”的组合，让抽象类比接口更侧重设计上的整体框架，而不仅仅是能力清单。

抽象行为的设计应聚焦领域本质契约

抽象方法不是随便加的，它应该代表该类体系中所有子类必然具备、但实现方式不同的核心能力。在设计时，需要回归业务语义，避免过度抽象或者粒度太细。比如在Animal类中定义abstract void makeSound()是合理的，因为每种动物都会发出声音，只是方式不同。但假如定义了一个abstract void eatGrass()，那就显得有问题了——肉食动物用不上这个能力，违背了“所有子类必须实现”的前提。真正需要差异化的行为才去抽象，共性行为尽量用具体方法来实现。这才是抽象类设计的本质所在。