Java继承为何不推荐？设计原则详解

有志者，事竟成！如果你在学习文章，那么本文《Java为何不推荐过度使用继承？设计原则解析》，就很适合你！文章讲解的知识点主要包括，若是你对本文感兴趣，或者是想搞懂其中某个知识点，就请你继续往下看吧~

继承滥用会导致子类脆弱、封装失效和LSP违规；应优先用组合+接口，仅在满足is-a清晰、契约稳定、不覆盖核心流程、模板方法收口四条件时才使用继承。

继承会让父类一改，子类全崩

这是最常踩的坑：你只是给 OrderService 的 validate() 方法加了个日志，结果 PromotionOrderService、RefundOrderService 等 17 个子类全报 NullPointerException 或逻辑错乱。因为它们都依赖父类中某个被悄悄修改的 protected 字段或方法执行顺序。

• 子类无法控制父类构造逻辑，一旦父类构造器里做了高风险操作（比如初始化第三方 SDK），子类实例化就可能直接失败
• 父类新增一个 protected void onInit()，而某个子类恰好已有同签名方法但语义不同，运行时行为就不可预测
• 多层继承（A → B → C → D）下，调试时得顺着调用链翻四层源码，还分不清哪一层改了哪一行

Java单继承 + protected暴露 = 封装形同虚设

写个 BaseCache 类，把 cacheMap 设为 protected 方便子类直接读写——结果所有子类都开始绕过 put() 和 evict() 方法，直接操作 cacheMap，导致缓存一致性彻底失控。

• protected 不是“受保护”，而是“半公开”：它把实现细节暴露给所有子类，等于把封装锁换成了弹簧门
• 接口（implements）只承诺行为，不暴露状态；而 extends 把字段、初始化顺序、方法调用链全打包塞给子类
• 想复用逻辑？用组合 + 接口回调更安全：private final CacheEngine engine = new CaffeineCacheEngine();，替换引擎只需改一行

里氏替换原则不是理论，是线上事故预警灯

有个 ImmutableListWrapper 继承 ArrayList，重写了 add() 抛异常。结果某处代码写着 if (list instanceof ArrayList) { list.add(item); }，一跑就崩——这违反了 LSP：子类不能让父类使用者的逻辑失效。

• 子类覆盖方法时，不能缩小访问权限（如 public → protected）、不能抛出父类没声明的受检异常、不能改变返回值的可变性语义
• 如果发现子类总在重写父类方法来“禁用”功能，说明继承关系错了，应该用组合 + 显式能力声明（比如 ReadonlyList 实现 ReadOnlyCollection 接口）
• 单元测试里加一条断言：assertThat(subInstance, is(instanceOf(Parent.class))); 不够，还得验证行为等价性

替代方案不是“不用继承”，而是“用对地方”

真要继承？只在满足这四个条件时才考虑：is-a 关系绝对清晰、父类契约稳定不变、子类不覆盖核心流程、扩展点通过模板方法严格收口（比如 abstract void doProcess()）。

• 日常业务对象（User、Order、Product）之间几乎不存在严格的 is-a，别硬套 BaseEntity 继承链
• 工具类、配置类、DTO 更不该被继承——用 @Builder、Record、interface default method 替代
• 框架集成（如 Spring 的 ApplicationRunner、MyBatis 的 BaseMapper）是少数合理继承场景，但注意它们本身已用模板方法封死了扩展边界

真正难的不是写 extends，是判断那个 new 出来的对象，到底该持有另一个对象，还是假装自己是它。

理论要掌握，实操不能落！以上关于《Java继承为何不推荐？设计原则详解》的详细介绍，大家都掌握了吧！如果想要继续提升自己的能力，那么就来关注golang学习网公众号吧！