抽象类在继承体系中充当关键中间隔离层，通过定义契约、封装共性、限制继承深度及协同接口泛型，实现解耦、复用与安全扩展。
抽象类在复杂继承体系中，主要通过定义契约、约束实现、隐藏细节来充当关键的中间隔离层。它不直接参与具体业务逻辑，也不暴露底层实现，而是划出一条清晰的“能力边界”，让上层调用者只依赖接口语义，下层子类只专注行为落地。
明确能力契约，解耦调用方与实现方
抽象类用abstract方法声明“必须提供什么功能”，但不规定“怎么实现”。上层代码面向抽象类编程，无需知道子类是MySQLDao还是RedisCache，只要它们都继承自DataAccessLayer抽象类并实现query()和save()，就能被统一调度。
- 调用方只依赖抽象类签名，编译期即稳定
- 新增子类（如MongoDao）不影响现有逻辑，符合开闭原则
- 替换实现时只需修改创建点（如工厂返回新实例），其余代码零改动
封装共性逻辑，避免重复与误用
抽象类可包含具体方法和字段，把跨子类的通用流程（如日志记录、参数校验、连接池管理）收拢到中间层。这些逻辑对子类透明，又不允许外部绕过——既减少重复编码，也防止调用方跳过关键步骤。
- 例如：abstract class ServiceTemplate { final void execute() { before(); doWork(); after(); } abstract void doWork(); }
- 子类只能重写doWork()，无法跳过before()/after()的预处理与后置动作
- 公共资源（如配置对象、线程上下文）可在抽象类中初始化并受保护访问
控制继承深度，限制不合理的扩展
抽象类天然形成继承断点。它本身不可实例化，强制子类必须实现抽象方法；同时，它可声明protected成员，只对直系子类可见，避免深层子类意外访问或覆盖关键内部状态。
- 比interface更严格：interface无法提供实现，也无法限制访问级别
- 比具体父类更安全：具体类若被误实例化，可能引发运行时错误；抽象类从语法上杜绝该风险
- 配合final方法，还能锁定某些流程骨架，仅开放有限钩子供定制
协同接口与泛型，支撑分层演进
抽象类常与接口组合使用：接口定义“能做什么”（What），抽象类解决“怎么做一半”（How Partially）。再配合泛型（如AbstractProcessor
- 例如：MessageHandler<Email> 和 MessageHandler<Sms> 共享解析、重试、监控等骨架，仅差异化序列化逻辑
- 抽象类中的泛型约束（如T extends Validatable）可提前拦截非法子类
- 当领域模型变化时，只需调整抽象类泛型边界或模板方法，影响范围可控
