多态通过将类型判断转移至对象自身行为来减少if-else，关键在于让调用方不再问“它是什么”而直接“请做这件事”；适用于有限类型判断、同类操作、逻辑差异明显且需扩展的场景，配合接口+实现类+工厂/注册表实现解耦，但参数差异、逻辑极简或动态计算值等情形不宜强行多态。
多态本身不直接“删掉”if-else，而是把原本散落在业务逻辑里的类型或状态判断，转移到对象自身行为中去。真正减少条件分支的关键，是让代码不再需要问“它是什么”，而是直接说“请做这件事”。
识别适合用多态的分支场景
不是所有if-else都该被替换。以下情况更适合引入多态：
- 判断依据是有限类型或枚举值，比如
order.getType()、file.getFormat() - 每个分支执行的是同一类操作，例如“导出”“计算折扣”“校验订单”
- 不同分支逻辑差异明显，且未来可能新增类型（如新增一种用户角色、一种支付方式）
用接口+实现类封装行为差异
别在service里写一长串if判断再调不同方法。定义统一接口，把差异逻辑下沉到具体类中：
- 声明接口：
interface Exporter { void export(Data data); } - 为每种格式写实现：
PdfExporter、DocxExporter、CsvExporter - 业务代码只写：
exporter.export(data)，完全不出现if (format.equals("pdf"))
配合工厂或注册表解耦创建与使用
避免在运行时用new硬编码实例，也别在调用处写switch选实现类：
- 用Map静态注册：
exporters.put("pdf", new PdfExporter()); exporters.put("docx", new DocxExporter()); - 调用时：
exporters.get(format).export(data) - 新增格式只需加一个类 + 注册一行，原业务逻辑零改动
注意边界：什么情况不该强行多态
多态不是银弹，滥用反而增加理解成本：
- 分支之间只是参数不同（比如税率、超时时间），更适合配置驱动或构造函数传参
- 逻辑极简（如仅返回不同字符串），拆成多个类得不偿失
- 判断依据是动态计算值（如
if (score > 90)），不属于类型/状态范畴，多态不适用
核心不在“用了接口”，而在“谁在决定行为”。当判断逻辑从调用方移进对象内部，条件分支自然就消失了。
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
