Java抽象类规范子类行为实现标准

在Java的世界里，抽象类是约束子类行为最经典的机制之一。它既不是接口那种纯声明，也不是普通类的全盘实现——抽象类处在中间，既是契约也是骨架。核心逻辑只有一句话：用abstract关键字在父类中留一个空方法，编译器会替你盯着，漏掉任何一个抽象方法都无法通过编译。

抽象类的设计逻辑并不复杂：包含抽象方法时，类必须标记为abstract且不能被new；抽象类可以有自己的构造器、字段和普通方法；抽象方法只写签名不写实现体，子类必须全部重写；配合final模板方法能固化流程，钩子方法提供可选扩展点；在继承链上，抽象方法最终由具体子类兜底实现；特别注意：构造器里千万别调用抽象方法。

我经常跟团队强调，编写抽象类就是在代码层面做契约设计——不是靠文档提醒，也不是靠人工审查，而是写完代码立即报错，漏一个方法都无法编译通过。

抽象类必须声明为 abstract，且不能被 new

只要类里有一个抽象方法，整个类就必须加abstract修饰；反过来，即使没有抽象方法，只要声明为abstract，也不能直接实例化。这是设计契约，而非运行实体。

• new Animal()会编译失败或运行时报错（例如TypeError或InstantiationException）
• 想测试基类逻辑？必须使用具体子类实例，或者通过mock构造函数
• 抽象类可以有构造器、字段、普通方法、静态成员——这些都能被子类继承复用

抽象方法必须由具体子类全部实现

抽象方法只定义签名（做什么），不写大括号、不写逻辑。它就像一张待签署的合同，子类一旦不是abstract，就必须签字履约。

• 参数类型必须完全一致：例如List和ArrayList不算重写
• 返回类型支持协变：父类返回Number，子类可返回Integer
• 访问修饰符不能更严格：父类public abstract，子类不能写成protected
• 不能用private/static/final修饰——它们与“被继承实现”的语义冲突

搭配模板方法，固化流程骨架

光留空还不够，真正落地要靠final模板方法：把不变的校验、日志、事务、包装等逻辑写死，只把变化点设为抽象方法，让子类专注于填空。

• 例如统一订单处理：validate() → calculateFee() → persist() → notify()
• 其中calculateFee()声明为protected abstract，各渠道子类各自实现计费规则
• 模板方法本身设为final，防止子类篡改执行顺序

用钩子方法区分“必须”和“可选”

除了强制实现的抽象方法，父类还可以提供空的protected方法作为扩展点，比如onAfterProcess()或afterSuccess()，子类按需重写，既不破坏契约又保留灵活性。

• 命名建议带onXXX或afterXXX前缀，语义清晰
• 风控子类重写它加审计日志，普通子类保持默认空实现即可
• 钩子方法与抽象方法互补：一个非填不可，一个可填可不填

注意继承链与初始化安全

抽象方法的约束沿继承链传递，但最终必须由某个具体子类兜底实现；同时要避开一个隐蔽陷阱：抽象类构造器里绝不能调用抽象方法。

• 抽象子类（如Mammal extends Animal）可以不实现抽象方法，作为中间层
• 具体子类（如Dog）必须实现整条继承链上所有未覆盖的抽象方法
• 构造器中调用抽象方法会导致子类字段尚未初始化，极易引发空指针