java继承是设计模式的结构性前提，支撑模板方法、工厂方法、装饰等模式落地，依赖is-a关系与多态机制，但受单继承限制需谨慎使用。
Java 中继承设计模式的实现基础，核心在于类层次结构的构建能力和运行时行为可替换性，而不是单纯语法上的 extends 关键字。它不是为“套用某个模式”而存在，而是让模板方法、策略（部分场景）、装饰（基类抽象）、工厂方法等模式得以落地的底层支撑。
继承是设计模式的结构性前提
很多经典模式依赖类之间的 is-a 关系才能成立：
- 模板方法模式：抽象父类定义算法骨架（如 prepare() → cook() → serve()），子类只重写 cook()。没有继承，就无法保证子类“一定是这个流程”的执行约束。
- 工厂方法模式：Creator 是抽象父类，声明 createProduct() 抽象方法；ConcreteCreator 继承它并实现具体创建逻辑。继承提供了统一接口 + 分散实现的结构基础。
- 装饰模式（抽象装饰器）：Decorator 类继承 Component，既持有 Component 引用，又与 Component 保持相同类型。这种“既是自身、又包装同类”的双重身份，靠继承 + 组合共同实现。
继承提供可预测的方法分发机制
设计模式常依赖“调用父类方法时，实际执行的是子类重写版本”这一特性：
- 子类重写方法必须满足签名一致、访问权限不收紧、异常范围不扩大——这是 JVM 方法调用规则对继承的硬性要求，也是多态能稳定工作的保障。
- 构造器链式调用（super() 隐式/显式）确保初始化顺序可控，使模板方法中“父类构造器触发钩子方法”这类设计成为可能。
- 静态成员和实例成员的加载/初始化顺序（父类静态 → 子类静态 → 父类实例块 → 父类构造 → 子类实例块 → 子类构造）为带状态的模式（如单例+继承变体）提供了可推演的生命周期。
继承的边界决定模式的适用边界
Java 只支持单继承，这直接影响了模式选型：
- 不能靠继承多个父类来组合行为，因此组合优于继承在策略、观察者等模式中更自然；
- 当需要“既有 A 行为、又有 B 行为”，且二者来自不同类体系时，只能通过接口实现（如 Runnable + Comparable），此时继承退居为接口实现的辅助手段；
- 过度依赖继承扩展会导致类层级僵化（比如 AbstractList → ArrayList → MyEnhancedArrayList → …），反而违背开闭原则——这时适配器或代理模式会更轻量。
真正起作用的是“受控的复用”而非“无条件继承”
继承本身不构成模式，它只是让以下设计意图可工程化：
- 父类封装不变逻辑，子类专注变化点（如不同支付渠道的 sign() 实现）；
- 统一类型声明下隐藏具体实现（List list = new ArrayList();），为策略切换、Mock 测试提供基础；
- 通过 protected 成员或钩子方法（hook method），暴露有限扩展点，防止子类破坏父类契约。
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
