Java多态本身不导致类爆炸，问题在于滥用继承、过早抽象或错误套用模式；应聚焦真实行为差异，用组合、策略、配置驱动替代冗余子类，控制子类数量，延迟抽象，避免构造器中虚方法调用。
Java 多态本身不导致类爆炸，但滥用继承、过早抽象或错误套用设计模式，容易引发“子类泛滥”——比如为每种支付方式建一个子类（WeChatPay、AlipayPay、UnionPay、ApplePay…），后续新增一种就得加一个类，测试、维护成本陡增。避免的关键不是少用多态，而是让多态服务于真实变化点，而非预设所有可能。
聚焦行为差异，而非对象种类
类爆炸常源于把“不同对象”当成“必须不同实现”的理由。其实多态应围绕“行为是否真有不可合并的逻辑差异”来判断。
- 如果只是参数不同（如支付金额、渠道 ID、回调地址），用策略入参或配置驱动更轻量，不必每个渠道一个类
- 如果真正差异在核心流程（如微信需拉起扫码页、银行卡需跳转网银、余额支付直接扣减），再考虑独立实现；否则统一走
PayHandler+ 条件分支或规则引擎 - 示例：不要写
class WeChatPay extends Payment和class AlipayPay extends Payment，而是定义interface PaymentProcessor，由一个UnifiedPaymentService根据 channel 字段路由到对应处理器——处理器可以是类，也可以是函数式实现
用组合替代深层继承树
继承层级一深（A → B → C → D），每加一个子类都可能牵连上层契约，也容易催生“只为覆盖某一行逻辑”而新建子类的惯性。
Java Development Manual
下载
Java开发手册规约集合，基于阿里巴巴Java开发手册（嵩山版）。 涵盖7大维度：编程规约、异常日志、单元测试、安全规约、MySQL数据库、工程结构、设计规约。 当用户需要：(1) 编写或审查Java代码 (2) 检查命名/代码规范 (3) 处理异常和日志 (4) 编写单元测试 (5) 安全编码 (6) 数据库设...
- 把可变部分抽成组件：比如“日志记录方式”“重试策略”“序列化格式”，通过构造函数或 Builder 注入，而不是靠继承切换
- 基类保持稳定：只保留真正通用的生命周期方法（如
init()、execute()、cleanup()），具体动作委托给组合对象 - 子类数量控制在 2–4 个以内；超过时，优先检查是否能把共性提到接口/抽象类，把差异收进配置或策略表
延迟抽象，让接口被至少两个实现复用
很多类爆炸始于“先建接口，再补实现”。但若目前只有一个实现，接口就是冗余抽象。
立即学习“Java免费学习笔记（深入）”；
- 先写一个具体类满足当前需求（如
CsvExporter） - 等第二个明显不同实现出现（如
PdfExporter），再提取Exporter接口，并让两者实现它 - 避免为“将来可能支持 JSON”提前建
JsonExporter类——它大概率长期空置，还占包结构、测试覆盖率和文档篇幅
警惕构造器里的虚方法调用陷阱
父类构造器中调用 protected init()，子类重写该方法并访问自身字段，极易引发 NullPointerException。为绕开这个坑，开发者有时会拆出一堆“初始化辅助类”，间接加剧类膨胀。
- 禁止在任何构造器中调用非
private或非static方法 - 改用两阶段初始化：构造器只做字段赋值，后续显式调用
start()或configure()方法承载业务逻辑 - 若必须解耦初始化，用工厂方法或 Builder 模式封装创建过程，而不是靠继承分发
