抽象类是Java中承担架构职责的关键构件，需以Abstract或Base为前缀命名、禁止重复前缀、文件名与类名一致；内部允许构造方法等但抽象方法禁用private/static/final；子类必须实现全部抽象方法或声明为abstract；应置于domain/core包，作为稳定契约需谨慎演进。
Java 中抽象类不是“可有可无的语法糖”，而是面向对象设计中承担架构职责的关键构件。它既不是接口的简化版，也不是普通类的变体，而是在继承体系中承上启下的“契约层”——既要定义共性行为，又要保留扩展空间。项目开发中若滥用或误用抽象类，轻则导致子类耦合僵硬，重则破坏开闭原则、增加维护成本。
命名与声明规范
抽象类必须以 Abstract 或 Base 为前缀（如 AbstractUserService、BaseOrderProcessor），这是团队可读性和代码扫描工具识别的关键信号。不能仅靠 abstract 关键字隐式表达意图。
- 类名使用大驼峰（PascalCase），且必须是名词或名词短语，体现其代表的“一类事物”而非动作
- 禁止出现
AbstractAbstractXXX或BaseBaseYYY等重复前缀 - 抽象类文件名必须与类名完全一致（如
AbstractPaymentStrategy.java），否则编译失败 - 不建议在抽象类中定义 public static void main(String[]) 方法——main 入口应放在具体启动类中，而非抽象层
结构与内容约束
抽象类内部是“有节制的自由”：允许包含构造方法、普通方法、字段、静态方法、final 方法，但对抽象方法和访问修饰符有明确限制。
- 抽象方法不能用
private、static、final修饰——因为它们无法被子类继承并实现 - 可以定义 protected 构造方法，供子类调用完成初始化（如校验必填参数）
- 普通方法建议只封装通用逻辑（如日志模板、空值预处理），避免业务分支判断；复杂流程应下沉到子类或委托给策略类
- 字段尽量设为
protected或提供 protected getter/setter，避免 public 字段暴露内部状态
继承与实现要求
子类继承抽象类不是“技术选择”，而是“契约履行”。一旦继承，就必须明确表态：是完整实现，还是继续抽象。
立即学习“Java免费学习笔记（深入）”；
- 非抽象子类必须覆写全部抽象方法，且需显式添加
@Override注解（OOP 规约强制要求） - 若子类无意/暂未实现全部抽象方法，必须声明为
abstract class XXX extends AbstractYYY，否则编译报错 - 禁止子类将父类已定义的普通方法重写为抽象方法（即不能把已有实现“降级”为 abstract）
- 抽象类之间可形成层级（如
AbstractEntity → AbstractAuditableEntity → AbstractTenantEntity），但深度建议 ≤3 层，避免继承链过长
工程与协作边界
抽象类是模块边界与职责划分的显性标识，在多人协作项目中直接影响 API 稳定性与演进节奏。
- 抽象类应置于 domain 或 core 包下（如
com.example.order.core.AbstractOrderService），不放在 impl 或 controller 层 - 对外发布的 SDK 或公共 jar 中，抽象类属于“稳定契约”，一旦发布，新增抽象方法会破坏所有子类编译，应通过默认方法（接口）或版本号升级解决
- 单元测试应覆盖抽象类中的普通方法逻辑，同时为每个具体子类编写测试，验证其对抽象方法的实现是否符合预期契约
- 文档注释（Javadoc）必须清晰说明：该抽象类的设计意图、适用场景、子类需注意的约束（如“子类必须保证
validate()在execute()前调用”）
