多态替代switch的核心是将类型判断逻辑移至对象自身行为中,通过接口定义统一操作(如discountpolicy.apply),各实现类封装具体逻辑,运行时动态绑定,配合工厂模式实现开闭原则;但仅适用于同操作多实现的场景。

用多态替代Switch分支,核心是把“根据类型做不同事”这件事,从条件判断转移到对象自身行为中——让每个类型自己决定怎么执行,而不是由外部代码来判断和分发。
用接口或抽象类定义统一行为
先识别Switch里所有case对应的操作,它们本质上是在对不同类型的对象执行同一类动作(比如“计算折扣”、“生成报表”、“处理支付”)。把这些动作提取成接口方法或抽象方法。
例如,原本Switch根据订单类型(NORMAL、VIP、PROMOTION)计算价格:
switch (orderType) {
case NORMAL: return amount * 0.9;
case VIP: return amount * 0.7;
case PROMOTION: return amount * 0.5 + 20;
}
可改为定义接口:
interface DiscountPolicy { double apply(double amount); }然后为每种策略实现该接口:
- NormalDiscount implements DiscountPolicy —— 实现apply返回amount * 0.9
- VipDiscount implements DiscountPolicy —— 返回amount * 0.7
- PromotionDiscount implements DiscountPolicy —— 返回amount * 0.5 + 20
运行时动态绑定,消除类型判断
不再在业务逻辑里写Switch,而是把具体策略对象作为参数传入,或通过工厂/配置获取。调用时直接policy.apply(amount),JVM自动调用对应子类的方法。
例如:
public class OrderService {
public double calculatePrice(Order order, DiscountPolicy policy) {
return policy.apply(order.getAmount()); // 无if,无switch
}
}
类型信息已封装在policy实例中,调用方无需关心当前是哪种策略。
配合策略模式+工厂,支持灵活扩展
新增一种折扣类型?只需新增一个实现类,再在工厂中注册映射关系,原有业务代码完全不用改。
工厂示例:
public class DiscountPolicyFactory {
private static final Map<string discountpolicy> POLICIES = Map.of(
"NORMAL", new NormalDiscount(),
"VIP", new VipDiscount(),
"PROMOTION", new PromotionDiscount()
);
<pre class="brush:java;toolbar:false;">public static DiscountPolicy get(String type) {
return POLICIES.getOrDefault(type, new NormalDiscount());
}
}
原来Switch的字符串判断,变成一次Map查找,后续扩展只需往Map里加新键值对,不碰老逻辑。
注意边界:不是所有Switch都适合替换
多态适合“同一种操作、多种实现”的场景。如果Switch里各case逻辑差异极大、毫无共性(比如一个case发短信、一个case写数据库、一个case调第三方API),强行抽象反而增加复杂度。
此时可考虑命令模式或规则引擎;若只是简单枚举转换(如状态码转字符串),用Enum自带方法更轻量。
关键看行为是否可统一建模——能定义出清晰的接口契约,多态才真正带来可维护性。
Java免费学习笔记:立即使用
解锁 Java 大师之旅:从入门到精通的终极指南











