抽象类核心是定义模板契约而非代码复用，强制子类实现抽象方法并支持字段、构造器及钩子模式；过度继承易引发维护与测试难题，应控制在单层。
抽象类用来定义模板契约，不是为了代码复用
Java里抽象类的核心作用不是“提供公共行为”，而是强制子类遵循统一接口规范。它把“哪些方法必须实现”和“哪些逻辑可以共享”分离开：抽象方法划出契约边界，具体方法才承担复用职责。如果只想要复用，用普通父类更合适；一旦出现 abstract 方法，就进入了模板设计模式范畴。
抽象类 vs 接口：什么时候必须选抽象类
当需要以下任一能力时，接口无法替代抽象类：
- 提供带状态的字段（
protected int count）或构造器逻辑 - 在方法中调用子类尚未实现的抽象方法（形成钩子模式，如
templateMethod()调用doStep1()和doStep2()） - 复用包含
this引用的非静态代码（接口默认方法无法访问实例字段）
例如网络请求基类常定义 protected HttpClient client 和 beforeExecute() 钩子，这些在接口里无法表达。
抽象类中构造器、字段、方法的可见性陷阱
抽象类的构造器虽不能直接 new，但子类构造时一定会隐式/显式调用它，因此：
立即学习“Java免费学习笔记（深入）”；
- 构造器可设为
protected，但不能是private（否则子类无法继承） -
protected字段会被子类直接访问，容易破坏封装；建议用protected final或 getter 封装 - 抽象方法默认无修饰符，但加上
protected会限制子类实现权限（子类只能用protected或public实现），通常保持默认（即public）更安全
abstract class DataProcessor {
protected final Logger logger = LoggerFactory.getLogger(getClass()); // OK
protected String configPath; // 风险：子类可随意改写
protected DataProcessor(String configPath) { // 必须是 protected 或 package-private
this.configPath = configPath;
}
public abstract void parse(byte[] data); // 不要加 protected！
}
抽象类被过度继承导致的维护难题
抽象类层级一旦超过两层（如 A → B → C），子类会同时受多层钩子和字段影响，调试时很难判断某行为来自哪一层。更隐蔽的问题是：
- 子类重写父抽象类方法时，若忘记调用
super.xxx()，可能跳过关键初始化（如资源注册） - 抽象类新增抽象方法，所有子类必须立刻响应，编译失败；而接口新增 default 方法则无此压力
- Mock 测试时，抽象类需用
PowerMockito或真实子类，比接口难 mock
实际项目中，优先用组合代替深层继承，抽象类控制在单层最稳妥——它本质是“强约束的骨架”，不是“越厚越好”的工具箱。
