多态可读性问题源于契约模糊、调用隐晦、调试困难，优化应聚焦“看得见、靠得住、查得清”：明确重写契约、优先接口、规避构造器中多态调用、日志打印实际类型、单元测试断言具体类型、策略模式替代伪多态分支。
多态本身不降低可读性，问题出在契约模糊、调用隐晦、调试困难这些具体实现环节。优化重点不是放弃多态，而是让多态“看得见、靠得住、查得清”。
明确方法重写的契约
父类方法没说清楚子类该做什么，调用方就只能猜——这是可读性崩塌的起点。
- 每个被重写的关键方法必须加 @Override，并在 Javadoc 中说明行为约束，比如：“返回值必须为正整数，且不依赖外部状态”
- 避免在父类中定义空实现或默认抛异常的方法，这类“占位符”会让读者反复确认子类是否真的覆盖了
- 接口比抽象类更适合作为多态入口，它天然聚焦行为，不带状态和构造逻辑干扰
控制多态触发的上下文
有些地方调用多态，运行时行为不可控，读者根本不敢信任结果。
- 禁止在构造器中调用 可能被重写 的方法——子类字段还没初始化，极易 NPE 或逻辑错乱
- 避免在静态方法、final 方法或类加载阶段（如 static 块）里触发多态调用
- 工厂方法返回类型尽量具体，比如返回 PaymentStrategy 而非 Object；若必须用泛型，配合 Class<? extends T> 显式传入类型
增强运行时可追溯性
IDE 点进去停在父类，是多态最常被诟病的一点。主动暴露类型信息，能大幅降低理解成本。
- 关键流程日志中打印实际类型，例如：log.info("Executing handler: {}", handler.getClass().getSimpleName());
- 调试时善用 IDE 的 “Evaluate Expression” 功能，输入 ((Object) obj).getClass() 快速确认实例类型
- 在单元测试中显式断言具体类型，比如 assertThat(handler, instanceOf(WechatPaymentHandler.class))，既是验证也是文档
用策略模式替代“伪多态”分支
如果发现多态类只是按枚举值切换行为，没有真正体现“不同形态”，那很可能用了假多态。
- 把 if (type == ORDER) { new OrderHandler(); } 这类工厂逻辑，换成 Map<String, Handler> 预注册，查找即调用，去掉条件判断又保留扩展性
- 枚举类本身实现接口（如 EventType.PROCESS.execute(event)），比一堆 if-else + new 更紧凑、更易维护
- 对简单场景，直接用 Lambda 表达式替代单方法子类，例如 handlers.put("sms", e -> sendSms(e))，语义清晰无额外类膨胀
