继承会建立父类与子类间的强耦合关系，导致子类依赖父类的实现细节，修改父类可能破坏子类，增加维护难度，降低代码灵活性。
在Java开发中，继承是面向对象编程的重要特性之一，它支持代码复用和多态。但过度使用或不恰当地使用继承会带来严重的维护问题。核心问题在于：继承会建立，导致父类的修改直接影响子类，从而引发“脆弱基类问题”。
继承带来的高耦合问题
当一个类继承另一个类时，它不仅继承了公开的方法，也继承了受保护的成员和实现细节。这意味着：
- 子类与父类的内部实现紧密绑定，父类一旦修改，子类可能意外失效
- 即使子类只用到父类的一小部分功能，也不得不承担整个父类的行为和依赖
- 多个子类共用一个父类时，父类为了满足某个子类而改动，可能破坏其他子类的逻辑
这种紧耦合让系统变得难以维护和扩展，特别是在大型项目中，一处修改可能引发连锁反应。
脆弱基类问题（Fragile Base Class Problem）
这是继承滥用最典型的副作用。所谓“脆弱基类”，是指父类的修改会“意外破坏”子类的行为。例如：
立即学习“Java免费学习笔记（深入）”；
- 父类新增一个方法，恰好与子类已有的方法签名冲突
- 父类修改某个受保护方法的逻辑，而子类依赖其原有行为
- 父类构造函数中调用了可被重写的方法，子类重写后导致初始化失败
Java中构造函数里调用虚方法就是一个典型陷阱：
class Parent {
public Parent() {
doSomething(); // 子类重写此方法，此时子类尚未初始化完成
}
protected void doSomething() { }
}
class Child extends Parent {
private String value = "initialized";
@Override
protected void doSomething() {
System.out.println(value.length()); // 可能抛出NullPointerException
}
}
上述代码中，父类构造过程中调用了可重写方法，而子类方法访问了尚未初始化的字段，极易引发运行时异常。
组合优于继承的设计原则
为避免继承带来的问题，推荐优先使用组合（Composition）而非继承。通过将功能封装在独立组件中，并在类中持有其引用，可以实现更灵活、低耦合的设计。
- 组合关系在运行时可以动态替换，继承则在编译期就固定
- 组合只暴露必要的接口，不暴露实现细节
- 更容易进行单元测试和模拟（Mock）
例如，与其让“汽车”继承“引擎”，不如让汽车包含一个引擎实例：
class Engine {
void start() { ... }
}
class Car {
private Engine engine; // 组合关系
void start() {
engine.start();
}
}
这样，引擎的变更不会直接影响汽车类的结构，且可以轻松更换不同类型的引擎。
基本上就这些。继承不是不能用，而是要谨慎使用。只有在明确的‘is-a’关系且不影响封装性的场景下才考虑继承。多数情况下，组合+接口更能构建稳定、可维护的系统。
