继承不直接等于模块化，但通过构建类层次结构、明确“is-a”关系、应用模板方法模式、结合接口与抽象类、限制继承深度，可有效支撑模块化设计。
继承本身不直接等于模块化，但它为模块化提供了关键支撑：通过建立清晰的类层次结构，把共性逻辑抽离到上层，让下层专注差异化实现，从而自然形成职责分明、可独立演进的代码单元。
明确“is-a”关系，划分模块边界
模块化不是随意拆分，而是按业务语义组织。继承强制要求子类与父类存在“是一种”的逻辑关系，比如 PaymentProcessor 是通用支付模块，WeChatPayProcessor 和 AlipayProcessor 是它的具体实现模块。这种关系天然界定模块职责——父类定义协议和骨架，子类封装细节，彼此边界清晰，互不影响。
模板方法模式驱动模块协作
父类用 final 方法封装流程主干（如 execute()），把可变步骤声明为 abstract 或 protected 方法，由子类实现。这样，整个业务流程成为一个稳定模块，而各环节的具体逻辑则分散在不同子类模块中。新增一种支付方式，只需新增一个子类，无需改动主流程，模块间低耦合。
配合接口与抽象类，增强模块可替换性
纯继承容易导致强依赖。更合理的做法是：父类定义为 abstract class 或搭配 interface。例如，ReportGenerator 作为抽象类提供通用导出逻辑，同时实现 Reportable 接口。这样上层模块只依赖接口，运行时可自由切换 SalesReport、UserReport 等不同模块，真正实现模块即插即用。
限制继承深度，避免模块过度耦合
模块化追求松耦合，而过深的继承链（如 A → B → C → D）会让底层模块变更牵连整个链条。实践中建议控制在 2–3 层以内。当发现子类需要频繁覆盖父类方法或访问大量 protected 成员时，往往意味着模块职责已混淆，应考虑用组合替代继承，把行为拆成独立的服务模块注入进来。
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
