优先使用组合而非继承，因组合支持运行时替换、降低耦合、符合单一职责；继承仅在满足“是”关系且父类明确设计为可继承时才安全。
继承用在“是”关系，组合用在“有”关系
判断一个设计该用继承还是组合，最直接的检验方式是读出类名之间的语义：如果 SubClass 是 SuperClass 的一种（比如 Dog 是 Animal），继承才合理；如果 Car 有 Engine，那就该用组合——强行让 Car extends Engine 会破坏封装，也违背里氏替换原则。
常见错误现象：IllegalArgumentException 在子类重写方法时突然抛出、父类 protected 字段被意外修改、单元测试中父类逻辑变更导致大量子类测试失败。这些往往不是代码写错了，而是本不该继承却用了继承。
- 继承暴露父类实现细节，组合通过接口或具体类型依赖控制可见性
- Java 不支持多继承，但可以组合多个对象（如
class OrderService { private PaymentProcessor processor; private NotificationSender sender; }） - 子类无法绕过父类构造器链，而组合对象可延迟初始化、可替换、可 mock
优先使用组合：从 has-a 到 delegates-to
组合不是简单地把字段塞进类里，关键在于委托（delegation）——让外部对象执行行为，当前类只做协调。例如，Stack 类不该继承 Vector（JDK 早期反面案例），而应持有 List 实例并把 push() 映射为 list.add()，pop() 映射为 list.remove(list.size()-1)。
这样做能避免继承带来的强耦合：你不需要关心 List 内部怎么扩容，也不用担心它哪天删掉某个 protected 方法。
立即学习“Java免费学习笔记（深入）”；
通过IB网关在Interactive Brokers上投资股票/ETF，使用与okx交易相同的人机确认环节，适用于用户请求检查时
- 组合对象可随时切换实现（
ArrayList→LinkedList→ 自定义缓存列表） - 组合支持运行时动态替换（如测试时注入
MockPaymentProcessor） - 组合天然支持单一职责：每个成员变量只负责一件事，不承担“既是容器又是算法”的双重角色
继承仅在满足三个条件时才安全
即便语义上成立，继承仍需满足：父类设计为被继承（有 protected 钩子、文档明确写出“可子类化”）、父类方法可被安全重写（无 final 且无隐式契约依赖）、子类能完全替代父类（里氏替换成立）。JDK 中 String、LocalDateTime 等不可继承，正是因它们内部状态复杂，无法保证子类不破坏不变量。
典型陷阱：HashSet 继承自 AbstractSet，但它重写了 add() 并引入了哈希表逻辑；若你再继承 HashSet 并试图重写 add()，很可能绕过其内部的 map.put() 调用，导致 size() 和实际元素数不一致。
- 检查父类是否有
final方法或private实现细节泄露（如通过toString()暴露内部结构） - 查看 JavaDoc 是否出现 “This class is designed for inheritance” 字样
- 用
@Override注解强制编译器校验，但别把它当成安全保证——它只管签名，不管语义
组合的代价：多一层转发，但换来长期可维护性
组合确实要多写几行委托代码，比如 public void start() { engine.start(); }。有人觉得这是样板代码，但比起继承后不得不阅读整个父类源码来理解行为边界，这点重复反而降低了认知负荷。
现代 IDE（IntelliJ / Eclipse）能一键生成委托方法，Lombok 的 @Delegate（需谨慎使用，它会忽略泛型擦除问题）也能减少手写量。真正难的是设计阶段就识别出哪些职责该剥离——这取决于对业务边界的判断，而不是语法是否简洁。
最容易被忽略的一点：组合不是“不用继承”的万能解药。当多个类共享同一套状态机逻辑（如不同协议解析器共用帧头校验、CRC 计算），抽象出一个 FrameProcessor 父类，比在每个类里复制粘贴或硬编码组合更清晰。这时候继承不是坏味道，而是有意为之的复用契约。
