替代if else 的方法---巧用枚举类和抽象方法

替代if else 的方法—巧用枚举类和抽象方法

使用场景:当接收到一些数据需要对其进行处理时,由于它们来自于不同的渠道(如:腾讯,巨量),不同渠道所需的处理方式不同,下面来写一个简单Demo来展示。

场景复现

  1. 首先构建一个 GeneralChannelRule 基础规则抽象类,定义一个抽象方法process(),不同的渠道都需要实现该抽象方法。
package com.cyc.basic.test.rule;

public abstract class GeneralChannelRule {
    /**
     * 处理逻辑
     */
    public abstract void process();
}
  1. 编写一个腾讯的规则类,设计对来及腾讯渠道的数据进行处理逻辑
package com.cyc.basic.test.rule;

public class TencentChannelRule extends GeneralChannelRule {
    @Override
    public void process() {
        // 腾讯处理逻辑
    }
}
  1. 编写一个巨量的规则类,定义具体对于巨量数据的处理逻辑
package com.cyc.basic.test.rule;


public class OceanEngineChannelRule extends GeneralChannelRule{
   @Override
    public void process() {
        // 巨量处理逻辑
    }
}
  1. 建立一个简单的枚举类
package com.cyc.basic.test.rule;

import lombok.Getter;

@Getter
public enum ChannelRuleEnum {
    /**
     * 巨量
     */
    OCEANENGINE("OCEANENGINE"),
    /**
     * 腾讯
     */
    TENCENT("TENCENT");

    public String code;

    ChannelRuleEnum(String code) {
        this.code = code;
    }
}
  1. 使用规则对数据进行处理。
package com.cyc.basic.test.rule;

import com.cyc.common.exception.ServiceException;

public class ProcessTest {
    public static void main(String[] args) {
        //模拟接收到的数据,其渠道为为巨量(OCEANENGINE),来自巨量的数据
        String sign = "OCEANENGINE";
        GeneralChannelRule rule;
        //根据对应渠道获取相应的具体规则实现类
        if (ChannelRuleEnum.TENCENT.code.equals(sign)) {
            rule = new TencentChannelRule();
        } else if (ChannelRuleEnum.OCEANENGINE.code.equals(sign)) {
            rule = new OceanEngineChannelRule();
        } else {
            //匹配不到,执行其他处理逻辑...
            throw new ServiceException("400", "传参有误");
        }
        //执行对应的数据处理
        rule.process();
    }
}

解析:如果通过上面的方式,则存在则两个缺点。

当我们需要新增新的渠道的时候,需要对main方法中的逻辑进行修改调整。这违背了设计模式中的开放封闭规则。开放封闭原则的核心的思想是软件实体是可扩展,而不可修改的。

也就是说,对扩展是开放的,而对修改是封闭的

新增渠道后,修改代码会产生大量的if else,后期维护起来很费劲。为了解决以上两个问题,可以借助枚举类来巧妙优化。

使用枚举处理

  1. 下面调整一下枚举类,枚举类中增加一个GeneralChannelRule属性,并且给对应渠道构建对应的GeneralChannelRule实现类,枚举类中新增一个matchRule() 匹配方法。
package com.cyc.basic.test.rule;

import lombok.Getter;

/**
 * @author fei
 */

@Getter
public enum ChannelRuleEnum {
    /**
     * 巨量
     */
    OCEANENGINE("OCEANENGINE"),
    /**
     * 腾讯
     */
    TENCENT("TENCENT");

    public String code;

    public GeneralChannelRule channel;

    ChannelRuleEnum(String code, GeneralChannelRule channel) {
        this.code = code;
        this.channel = channel;
    }

    //匹配规则
    public static ChannelRuleEnum matchRule(String code){
        ChannelRuleEnum[] values = ChannelRuleEnum.values();
        for (ChannelRuleEnum value : values) {
            if(value.code.equals(code)){
                return value;
            }
        }
        return null;
    }

    ChannelRuleEnum(String code) {
        this.code = code;
    }
}

2、改写程序

public class ProcessTestNew {
    public static void main(String[] args) {
        String sign = "TOUTIAO";
        ChannelRuleEnum channelRule = ChannelRuleEnum.matchRule(sign);
        if (Objects.isNull(channelRule)) {
            throw new ServiceException("400", "没有匹配上对应规则");
        }
        GeneralChannelRule rule = channelRule.channel;
        rule.process();
    }
}

解析:通过使用枚举类,在枚举中将 key 与 规则具体实现进行绑定。经过此番优化,

可以减少if -else使得代码更加简介,后期如果需要新增渠道,只需要在编写具体规则实现类并继承GeneralChannelRule抽象类,并在枚举类中新增的对应枚举,而不需要改动原先的任何代码。符合开发封闭原则。

<think>嗯,用户问的是“大量ifelse都能改策略模式吗”。之前他问过策略模式的基本介绍,现在可能在实际项目中遇到了大量的if-else语句,想了解是否都能用策略模式来优化。首先,我需要确认用户的使用场景。他可能是在维护一个代码库,里面有很多条件判断,导致代码难以维护扩展。用户的身份可能是一个中级开发人员,想要提升代码质量,学习设计模式的应用。 接下来,用户的真实需求是了解策略模式是否适用于所有if-else的情况,还是有特定的适用条件。深层需求可能包括如何判断何时使用策略模式,以及替代if-else的其他方法,避免过度设计。此外,用户可能希望知道策略模式的优缺点,以便权衡是否采用。 首先,我需要明确策略模式适用的场景,比如当多个算法或行为需要动态切换时。然后,指出并非所有if-else都能或都应该用策略模式替换。例如,简单的条件判断可能不值得引入策略模式,而复杂的、频繁变更的条件更适合。同时,要提醒用户注意策略类数量爆炸的问题,以及维护成本。 可能还需要对比其他替代方案,比如状态模式、工厂模式、枚举策略等,让用户有更多选择。同时,给出实际例子帮助理解,比如支付方式与订单状态处理的区别,说明策略模式适用的具体情况。 最后,总结适用场景替代方案,帮助用户做出决策。需要确保回答结构清晰,分点说明,让用户容易理解。还要注意语言简洁,避免技术术语过多,保持口语化但专业。</think>关于是否所有if-else都可以用策略模式重构,需要分情况讨论。以下从适用场景、改造原则替代方案三个维度进行详细分析: --- ### 一、适用场景(适合改造的情况) 1. **行为类型明确** -if-else块处理的是同一类业务行为的不同算法实现时 - ✅ 示例:支付方式选择 ```java if(paymentType == "alipay") { ... } else if(paymentType == "wechat") { ... } ``` 2. **高频变更需求** - 当新增/修改条件分支的需求频繁发生时 - ✅ 示例:折扣策略系统 ```java if(discountType == "FULL_100_MINUS_20") { ... } else if(discountType == "RATE_0.8") { ... } ``` 3. **条件复杂度高** - 每个分支包含大量独立逻辑(>10行代码) - ✅ 示例:文件解析器选择 ```java if(fileType == "CSV") { parseCSV(); } else if(fileType == "XML") { parseXML(); } ``` --- ### 二、不适合改造的情况 1. **简单状态判断** - ❌ 示例:订单状态流转 ```java if(status == "PAID") { sendGoods(); } else if(status == "UNPAID") { remindPayment(); } ``` - ✅ 更适合用**状态模式**而非策略模式 2. **顺序依赖判断** - ❌ 示例:校验链 ```java if(!checkNull()) return; else if(!checkFormat()) return; else if(!checkBusinessRule()) return; ``` - ✅ 更适合用**责任链模式** 3. **临时条件判断** - ❌ 示例:临时业务开关 ```java if(config.get("feature_flag") == true) { ... } ``` - ✅ 保持简单判断更合适 --- ### 三、改造方法论 #### 改造步骤示例(以支付场景为例) **原始代码:** ```java public void processPayment(String type, int amount) { if("credit".equals(type)) { // 50行信用卡支付逻辑 } else if("alipay".equals(type)) { // 40行支付宝支付逻辑 } else if("wechat".equals(type)) { // 45行微信支付逻辑 } } ``` **策略模式改造:** 1. 定义策略接口 ```java interface PaymentStrategy { void pay(int amount); } ``` 2. 实现具体策略 ```java class CreditCardStrategy implements PaymentStrategy { public void pay(int amount) { /* 原信用卡逻辑 */ } } class AlipayStrategy implements PaymentStrategy { public void pay(int amount) { /* 原支付宝逻辑 */ } } ``` 3. 创建策略工厂(关键改造点) ```java class PaymentStrategyFactory { private static Map<String, PaymentStrategy> strategies = new HashMap<>(); static { strategies.put("credit", new CreditCardStrategy()); strategies.put("alipay", new AlipayStrategy()); strategies.put("wechat", new WeChatStrategy()); } public static PaymentStrategy getStrategy(String type) { return strategies.get(type); } } ``` 4. 重构业务方法 ```java public void processPayment(String type, int amount) { PaymentStrategy strategy = PaymentStrategyFactory.getStrategy(type); if(strategy != null) { strategy.pay(amount); } } ``` --- ### 四、替代方案参考 | 方案类型 | 适用场景 | 示例实现 | |----------------|----------------------------------|----------------------------------| | **枚举策略** | 策略数量固定且简单 | 用枚举类封装各策略实现 | | **函数式接口** | JDK8+环境,简单策略 | 使用`Function`/`Consumer`接口 | | **规则引擎** | 超复杂条件组合(如风控系统) | Drools等规则引擎实现 | | **模板方法** | 有公共流程+差异化步骤 | 抽象类定义骨架+子类实现具体步骤 | --- ### 五、改造收益评估表 | 评估维度 | 改造前(if-else) | 改造后(策略模式) | |----------------|----------------|------------------| | 扩展成本 | 修改原方法 | 新增策略类即可 | | 单元测试 | 需整体测试 | 可单独测试策略 | | 代码可读性 | 条件臃肿 | 结构清晰 | | 内存消耗 | 无额外开销 | 需要对象池优化 | | 团队理解成本 | 低 | 中(需模式知识) | --- ### 关键结论 1. **非全量改造**:仅建议对符合"算法族切换"特征的复杂条件进行改造 2. **平衡原则**:评估维护成本与收益,避免为模式而模式 3. **组合使用**:可配合工厂模式+策略模式实现更优雅的解决方案 4. **渐进式重构**:优先改造变动最频繁的条件分支 实际案例:某电商系统将原有的28个if-else支付分支改造成策略模式后,新支付渠道接入时间从2天缩短至2小时,但增加了约15%的内存消耗。这种取舍需要根据具体业务场景权衡。
评论 3
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包

打赏作者

意田天

你的鼓励将是我创作的最大动力

¥1 ¥2 ¥4 ¥6 ¥10 ¥20
扫码支付:¥1
获取中
扫码支付

您的余额不足,请更换扫码支付或充值

打赏作者

实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值