继承应控制在2～3层内，每层须对应真实、稳定、可命名的业务抽象；组合更推荐，因其体现has-a关系，支持运行时替换、职责分离与测试隔离，适用于订单服务持有paymentprocessor等场景；继承仅适用于框架级骨架协议，如spring abstractcontroller。

在大型企业级架构中，继承不是“能用就用”，而是“该用才用”。它本质是建模is-a关系的工具，不是代码复用的万能捷径。过度拉长继承链（比如 A → B → C → D → E）会带来耦合紧、修改风险高、理解成本大等问题。真正合理的做法，是把继承控制在2～3层以内，同时默认倾向用组合+接口替代深层继承。

继承层级怎么才算合理？

合理层级的核心标准不是“层数少”，而是每层都对应一个真实、稳定、可命名的业务抽象”。例如：

• 顶层抽象类（如 OrganizationUnit）：定义组织单元共性——编码、名称、负责人、创建时间，不涉及预算、人员结构等具体职责；
• 中间层具体类（如 Department）：明确代表“部门”这个角色，封装预算池、下属单位列表、审批流程等语义清晰的能力；
• 底层实现类（如 EngineeringTeam）：体现“研发团队”的专属行为——技术栈管理、迭代周期配置、CI/CD集成点。

超过三层，往往意味着中间某一层只是“过渡壳”，没有独立业务含义，这时就应该考虑拆解或重构。

为什么组合比继承更受推荐？

组合体现的是has-a或uses-a关系，天然支持运行时动态替换、职责分离和测试隔离。在企业系统中，它比继承更灵活、更安全：

Alibabacloud Sdk Client Initialization For Java

在 Java 中初始化和管理阿里云 SDK客户端。包括单例模式、线程安全、endpoint 与 region 配置、VPC 终端节点、同步与异步等。

下载

• 一个订单服务不需要继承“支付服务”或“物流服务”，而是持有 PaymentProcessor 和 DeliveryScheduler 实例；
• 当需要切换支付宝为微信支付时，只需替换组合对象，无需改动订单类结构，也不影响其他子类；
• 每个行为组件可单独测试、监控、降级，而深层继承链中一个父类改错，可能让所有子类集体失效。

什么时候必须用继承？

继承不可替代的典型场景，是构建框架级骨架协议：

• Spring 的 AbstractController 提供统一参数解析、异常包装、跨域处理，但把 handleRequest() 留为模板方法——这是典型的“流程固定、细节开放”；
• 报表引擎中，abstract class ReportGenerator 定义 buildData() 和 formatOutput() 抽象方法，强制所有子类回答“数据从哪来”“格式怎么定”，确保关键路径不缺失；
• 权限模型里，abstract class AccessDecisionManager 统一执行鉴权主干，子类只决定“谁有权限”，不重复写日志、审计、缓存逻辑。

如何落地“优先组合、慎用继承”？

这不是一句口号，而是可操作的设计习惯：

• 新建类前先问：它是不是某个概念的特化？还是它只是用到了某些能力？ 如果答案是后者，直接上组合；
• 已有继承链超过三层，用 IDE 的“Extract Interface”或“Move Method”辅助识别哪些能力可剥离为独立组件；
• 父类新增字段或方法前，确认是否所有子类都真正需要——如果只有部分子类用到，说明它本不该在父类；
• 用接口定义契约（如 Reportable、Exportable），让类按需实现，而不是被迫继承一大串无关功能。

不复杂但容易忽略：继承是架构的骨骼，组合是肌肉与神经。骨骼要稳而少，肌肉要活而专。

Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南