新增enum枚举值时如何避免修改大量代码以提升可扩展性？

这个问题是枚举集中式分支判断的典型场景，目前业内有两种成熟的改造方向，可以完全解决新增枚举值需要多处在改代码的问题：

方案1：将业务行为抽象到枚举内部（适合行为属于枚举自身属性的场景） #

把不同枚举值对应的业务逻辑直接定义为枚举的抽象方法，每个枚举实例独立实现对应逻辑，改造后的枚举示例如下：

public enum MyEnum {
    FIRST {
        @Override
        public void boo() {
            // 原FIRST分支的boo逻辑
        }
        @Override
        public int goo() {
            // 原FIRST分支的goo逻辑
        }
        @Override
        public AnotherObject foo() {
            // 原FIRST分支的foo逻辑
        }
        @Override
        public double doo() {
            // 原FIRST分支的doo逻辑
        }
        @Override
        public void soo() {
            // 原FIRST分支的soo逻辑
        }
        @Override
        public boolean xoo() {
            // 原FIRST分支的xoo逻辑
        }
    },
    SECOND {
        // 实现所有抽象方法，写入SECOND对应的分支逻辑
    },
    THIRD {
        // 实现所有抽象方法，写入THIRD对应的分支逻辑
    },
    FOURTH {
        // 实现所有抽象方法，写入FOURTH对应的分支逻辑
    };

    // 把所有和枚举值强关联的行为定义为抽象方法
    public abstract void boo();
    public abstract int goo();
    public abstract AnotherObject foo();
    public abstract double doo();
    public abstract void soo();
    public abstract boolean xoo();
}

改造完成后，原有A、B类中的switch逻辑可以完全删除，直接调用枚举的方法即可：

public class A
{
    private MyEnum myEnum
    
    public A(MyEnum myEnum)
    {
        this.myEnum = myEnum;
    }
    
    public void boo()
    {
        myEnum.boo();
    }

    public int goo()
    {
        return myEnum.goo();
    }
   

    public AnotherObject foo()
    {
        return myEnum.foo();
    }
}

后续新增枚举值时，仅需要在枚举类中添加新的实例、实现所有抽象方法即可，不需要修改A、B等任何业务类的代码，完全符合开闭原则。

方案2：策略模式+工厂映射（适合行为不属于枚举自身、不同业务域逻辑差异大的场景） #

如果部分业务逻辑是特定业务类专属、不适合耦合到枚举中，可以采用策略模式拆分逻辑，以A类的业务逻辑为例：

1. 定义A业务域的枚举行为策略接口

public interface MyEnumAStrategy {
    void boo();
    int goo();
    AnotherObject foo();
}

2. 每个枚举值对应实现独立的策略类

public class FirstAStrategy implements MyEnumAStrategy {
    @Override
    public void boo() { 
        // FIRST对应A类的boo逻辑 
    }
    @Override
    public int goo() { 
        // FIRST对应A类的goo逻辑 
    }
    @Override
    public AnotherObject foo() { 
        // FIRST对应A类的foo逻辑 
    }
}
// 同理实现SecondAStrategy、ThirdAStrategy、FourthAStrategy

3. 定义工厂类维护枚举和策略的映射关系

public class MyEnumAStrategyFactory {
    private static final Map<MyEnum, MyEnumAStrategy> STRATEGY_MAP = Map.of(
        MyEnum.FIRST, new FirstAStrategy(),
        MyEnum.SECOND, new SecondAStrategy(),
        MyEnum.THIRD, new ThirdAStrategy(),
        MyEnum.FOURTH, new FourthAStrategy()
    );

    public static MyEnumAStrategy getStrategy(MyEnum myEnum) {
        return STRATEGY_MAP.get(myEnum);
    }
}

4. 改造A类代码，删除所有switch逻辑

public class A {
    private MyEnumAStrategy strategy;
    
    public A(MyEnum myEnum) {
        this.strategy = MyEnumAStrategyFactory.getStrategy(myEnum);
    }
    
    public void boo() {
        strategy.boo();
    }

    public int goo() {
        return strategy.goo();
    }

    public AnotherObject foo() {
        return strategy.foo();
    }
}

B类的业务逻辑可以参照上述流程单独定义专属的策略体系，后续新增枚举值时，仅需要新增对应策略实现、在工厂的Map中添加一行映射即可，不需要改动原有业务逻辑。

额外优化建议 #

• 上述两种方案都自带编译期检查能力，漏实现方法/策略会直接编译报错，比传统switch漏写分支只会出现运行时问题更安全
• 如果使用Java 17及以上版本，可以配合密封类+模式匹配switch的穷尽性检查能力，进一步降低逻辑遗漏的风险

内容的提问来源于stack exchange，提问作者MarekChr