继承可能破坏封装因子类依赖父类实现，父类变更影响子类行为，且可重写方法易引发风险；组合通过对象聚合实现功能复用，支持运行时动态替换、降低耦合、避免接口污染，并允许多重角色组合，更利于维护和扩展。
Java中的继承在某些情况下确实可能破坏封装，而组合通常被认为更灵活、更安全的设计选择。这并不是说继承本身是错误的，而是它的使用方式容易导致设计上的问题。
继承为何可能破坏封装
封装的核心是隐藏对象的内部实现细节，仅通过公共接口与外界交互。继承在以下方面可能削弱这种封装性：
- 子类依赖父类的实现细节：子类会直接访问或重写父类的方法和字段，一旦父类内部逻辑发生变化，子类的行为可能意外改变，即使子类代码没有修改。
- 父类方法暴露过多行为：如果父类提供了可被重写的方法（非final），子类可以改变其行为，从而影响整个调用链。比如父类构造函数中调用了可重写的方法，可能导致子类在初始化未完成时就被调用，引发空指针等问题。
- 打破“黑箱”原则：理想的封装应该是使用者无需知道内部如何工作。但继承要求子类了解父类的工作机制才能正确扩展，这就违背了封装的初衷。
组合为什么更灵活
组合是指一个类通过持有其他类的实例来获得功能，而不是通过继承。这种方式在设计上更具优势：
- 运行时动态替换行为：通过接口或抽象类引用成员对象，可以在运行时更换具体实现，比如策略模式中切换算法，而继承是编译期确定的，无法动态改变。
- 避免继承带来的紧耦合：组合关系比继承关系松散。类之间通过接口通信，不依赖具体实现，修改一个类不容易波及另一个。
- 更精细的控制权：使用组合时，你可以决定暴露哪些方法给外部，甚至可以包装、过滤或增强被包含对象的行为，而继承会自动继承所有非私有成员，容易造成接口污染。
- 支持多角色能力：Java不支持多重继承，但一个类可以拥有多个不同类型的组件对象，从而实现多种职责的组合，更加贴近实际需求。
实际例子对比
假设你要实现一个“可飞行的汽车”：
立即学习“Java免费学习笔记（深入）”；
- 用继承：你可能会让Car extends Flyable，但如果Flyable有特定的引擎逻辑，Car就不得不接受这些实现，哪怕并不适用。
- 用组合：Car类中包含一个FlightComponent对象，需要飞行时调用它。你可以随时更换不同的飞行模块，甚至在运行时关闭飞行功能。
基本上就这些。继承不是完全不能用，但在大多数扩展场景下，优先考虑组合能带来更好的可维护性和灵活性。设计原则中“优先使用对象组合而非继承”正是基于这样的实践经验。
评论（已关闭）
评论已关闭