扩展Type枚举后的Plan类如何优化结构？求最佳设计方案

针对你遇到的这个问题，策略模式是最适合的解决方案——它能完美拆分不同Plan类型的差异化行为，让代码更易扩展、更符合开闭原则，彻底解决check方法无法通用的问题。

为什么策略模式合适？ #

你的核心痛点是：不同的Type对应不同的检查逻辑，但当前的设计把这些逻辑都堆在Plan类里，导致新增类型时必须修改原有类，还会出现方法和类型不匹配的问题。策略模式的核心就是把可变的行为（这里的check逻辑）封装成独立的策略类，让Plan类只负责持有策略、调用策略，而不关心具体的实现细节。

具体重构步骤 #

1. 定义检查策略接口 #

先把通用的检查行为抽象成接口：

interface CheckStrategy {
    String check();
}

2. 为每种类型实现对应的策略类 #

把原来的checkFoo()和checkBar()逻辑分别移到独立的策略类中：

// FOO类型的检查策略
class FooCheckStrategy implements CheckStrategy {
    @Override
    public String check() {
        // 原来checkFoo()里的检查逻辑
        return "FOO类型检查通过";
    }
}

// BAR类型的检查策略
class BarCheckStrategy implements CheckStrategy {
    @Override
    public String check() {
        // 原来checkBar()里的检查逻辑
        return "BAR类型检查通过";
    }
}

3. 修改Plan类，绑定策略与类型 #

把Plan类里的独立check方法去掉，改为通过枚举绑定对应的策略，对外提供统一的check()方法：

class Plan {
    public enum Type {
        FOO(new FooCheckStrategy()),
        BAR(new BarCheckStrategy());

        private final CheckStrategy checkStrategy;

        // 枚举构造方法，绑定对应策略
        Type(CheckStrategy strategy) {
            this.checkStrategy = strategy;
        }

        public CheckStrategy getCheckStrategy() {
            return checkStrategy;
        }
    }

    private final Type type;

    public Plan(Type type) {
        this.type = type;
    }

    // 对外提供统一的检查方法
    public String check() {
        return type.getCheckStrategy().check();
    }

    // 原有通用方法保留
    String doSomething() {
        // 原有逻辑
        return "执行通用操作";
    }
}

关于“是否需要加检查抛异常”的问题 #

在重构后的策略模式结构里，完全不需要额外加检查或抛异常：

• 每个Plan实例的type是固定的，对应的策略也是枚举预先绑定好的，调用check()时只会执行对应类型的逻辑，不会出现“用FOO的检查逻辑处理BAR类型”的情况。
• 如果是旧代码结构（没重构前），确实需要在checkFoo()和checkBar()里加类型检查（比如判断当前Plan的Type是不是对应类型，不是就抛IllegalArgumentException），但重构后这个问题就从根源上解决了。

其他可选的通用方案 #

除了策略模式，还有一种常见的方案是利用多态（继承+抽象类）：

// 抽象Plan类，定义通用方法和抽象检查方法
abstract class Plan {
    abstract String check();

    String doSomething() {
        // 通用逻辑
        return "执行通用操作";
    }
}

// FOO类型的Plan实现
class FooPlan extends Plan {
    @Override
    String check() {
        return "FOO类型检查通过";
    }
}

// BAR类型的Plan实现
class BarPlan extends Plan {
    @Override
    String check() {
        return "BAR类型检查通过";
    }
}

这种方案也能解决问题，但相比策略模式，继承的耦合度更高——如果后续需要给Plan新增通用属性/方法，继承没问题，但如果检查逻辑需要复用（比如其他类也要用FOO的检查逻辑），策略模式的灵活性会更强。

总结 #

优先选择策略模式，它不仅解决了当前的方法不通用问题，还为后续新增类型（比如BAZ）提供了极低的扩展成本——只需要新增一个策略类和枚举项，完全不需要修改原有代码，完美符合开闭原则。

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