Laravel重构巨型if语句：主题插件选择逻辑优化求助

这种多分支条件判断膨胀的问题我太懂了！之前维护过一个类似的项目，一开始是4个分支，后来加了新需求直接涨到8个，代码乱得像一团麻。分享几个我亲测有效的重构思路，帮你把臃肿的逻辑拆解开：

1. 用策略模式拆分场景逻辑 #

策略模式简直是这种「根据不同选择执行不同业务」场景的救星。你可以把「都不选」「只选主题」「只选插件」「两者都选」这四种场景，分别封装成独立的策略类，每个类只负责自己的业务逻辑，完全隔离。

先定义一个统一的策略接口，约束所有策略类的方法：

interface StoreStrategyInterface {
    public function handle(Request $request);
}

然后针对每个场景写具体的策略实现：

// 什么都没选的场景
class NoSelectionStrategy implements StoreStrategyInterface {
    public function handle(Request $request) {
        // 这里写对应业务逻辑，比如初始化默认配置
    }
}

// 只选主题的场景
class OnlyThemeStrategy implements StoreStrategyInterface {
    public function handle(Request $request) {
        // 处理主题校验、关联、存储等逻辑
    }
}

// 只选插件的场景
class OnlyPluginStrategy implements StoreStrategyInterface {
    public function handle(Request $request) {
        // 处理插件的校验、激活、存储等逻辑
    }
}

// 主题和插件都选的场景
class ThemeAndPluginStrategy implements StoreStrategyInterface {
    public function handle(Request $request) {
        // 同时处理主题和插件的逻辑，也可以复用上面两个类的方法
    }
}

接下来改造你的store方法，只需要根据用户选择匹配对应的策略，执行逻辑即可：

public function store(Request $request) {
    // 根据请求参数匹配策略
    $strategy = match(true) {
        !$request->has('theme') && !$request->has('plugin') => new NoSelectionStrategy(),
        $request->has('theme') && !$request->has('plugin') => new OnlyThemeStrategy(),
        !$request->has('theme') && $request->has('plugin') => new OnlyPluginStrategy(),
        default => new ThemeAndPluginStrategy()
    };

    return $strategy->handle($request);
}

这样一来，原来臃肿的if分支被拆成了一个个职责单一的类，后续要修改某个场景的逻辑，直接改对应的策略类就行，完全不会影响其他分支，维护成本直线下降。

2. 用工厂模式优化策略创建 #

如果后续策略类变多，或者需要动态创建策略，可以加个工厂类统一管理策略的实例化，让store方法更简洁：

class StoreStrategyFactory {
    public static function create(Request $request): StoreStrategyInterface {
        return match(true) {
            !$request->has('theme') && !$request->has('plugin') => new NoSelectionStrategy(),
            $request->has('theme') && !$request->has('plugin') => new OnlyThemeStrategy(),
            !$request->has('theme') && $request->has('plugin') => new OnlyPluginStrategy(),
            default => new ThemeAndPluginStrategy()
        };
    }
}

然后store方法就变得非常清爽：

public function store(Request $request) {
    $strategy = StoreStrategyFactory::create($request);
    return $strategy->handle($request);
}

3. 为什么Repository模式效果不佳？ #

Repository模式的核心是封装数据访问逻辑，比如数据库查询、ORM操作等，但你的问题本质是业务逻辑的分支判断过多。所以用Repository只能优化数据层的代码，没法从根本上拆分业务分支的复杂度，策略模式才是对症的方案。

另外，你还可以把请求参数的判断逻辑封装到自定义Request类里，提升代码可读性：

// 自定义Request类中新增方法
public function getSelectionType(): string {
    $hasTheme = $this->has('theme');
    $hasPlugin = $this->has('plugin');

    if (!$hasTheme && !$hasPlugin) return 'none';
    if ($hasTheme && !$hasPlugin) return 'only_theme';
    if (!$hasTheme && $hasPlugin) return 'only_plugin';
    return 'both';
}

然后工厂类里就可以用更清晰的匹配逻辑：

class StoreStrategyFactory {
    public static function create(Request $request): StoreStrategyInterface {
        return match($request->getSelectionType()) {
            'none' => new NoSelectionStrategy(),
            'only_theme' => new OnlyThemeStrategy(),
            'only_plugin' => new OnlyPluginStrategy(),
            'both' => new ThemeAndPluginStrategy()
        };
    }
}

这种结构完全符合开闭原则，后续如果新增「选皮肤」之类的新场景，只需要新增对应的策略类，再在工厂里加个匹配项就行，不用修改原有代码。

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