策略模式替代服务定位器：依赖注入更优雅

本文深入探讨了如何在策略模式中优雅地避免使用服务定位器这一反模式，转而采用依赖注入（DI）实现更简洁、可维护的代码结构。传统策略模式常借助服务定位器动态获取策略实例，但这种方式会引入隐藏依赖，降低代码可测试性和可维护性。 文章提出利用DI容器自动收集策略实现，并结合策略接口的自判断机制，构建一个高效的策略解析器。通过将所有策略接口的实现注入到策略解析器中，并为每个策略添加`appliesTo`方法来判断适用性，有效避免了冗长的if-else链。此外，文章还讨论了健壮性考虑，引入默认策略来处理未预期情况。最终，本文总结了使用依赖注入的优势，强调解耦性、可测试性、可扩展性和代码简洁性，为开发者提供了在策略模式中实现依赖注入的最佳实践。

1. 策略模式与服务定位器的困境

策略模式（Strategy Pattern）是一种行为设计模式，它允许在运行时选择算法的行为。通过定义一系列算法，将每一个算法封装起来，并使它们可以相互替换，使得算法的变化独立于使用算法的客户端。然而，在实现策略模式时，一个常见的陷阱是引入服务定位器（Service Locator）模式来动态获取具体的策略实例。

考虑以下伪代码示例，其中 StrategyResolver 依赖于 ServiceLocator 来获取 StrategyInterface 的不同实现：

// 策略接口
interface StrategyInterface {
    // ...
}

// 具体策略实现，可能包含依赖
class A implements StrategyInterface {
    private Dependency dep;
    constructor(Dependency dep) {
        this.dep = dep;
    }
}

class B implements StrategyInterface { /* ... */ }
class C implements StrategyInterface { /* ... */ }

// 策略解析器，使用服务定位器
class StrategyResolver {
    private ServiceLocator locator;

    constructor(ServiceLocator locator) {
        this.locator = locator;
    }

    public StrategyInterface resolve(String data) {
        if (data.equals("xxx")) {
            return locator.get(A.class); // 通过服务定位器获取实例
        } else if (data.equals("yyy")) {
            return locator.get(B.class);
        }
        return locator.get(C.class);
    }
}

尽管服务定位器可以在运行时提供所需的依赖，但它被广泛认为是反模式，因为它引入了隐藏的依赖，使得代码难以测试和维护。StrategyResolver 不知道它所依赖的策略具体是什么，只知道如何向定位器请求。此外，如果策略 A, B, C 本身有复杂的依赖，服务定位器会使得这些依赖的解析变得不透明。当策略数量增多时，StrategyResolver 中的 if-else 链会变得冗长且难以管理。

2. 策略模式的依赖注入优化

为了避免服务定位器带来的问题，我们可以充分利用现代依赖注入（DI）框架（如Spring、Guice等）的强大功能。核心思想是让DI容器自动收集所有实现了特定接口的策略，并将它们作为一个集合注入到策略解析器中。

2.1 注入策略集合

DI容器能够识别并注入特定类型的所有已知Bean。对于策略模式，这意味着我们可以将所有 Strategy 接口的实现注入到一个列表中。

import java.util.List;
import java.util.ArrayList;
import java.util.Optional;
import javax.inject.Named; // 或 Spring 的 @Component, @Service 等

// 策略接口：推荐简化接口命名，去除 'Interface' 后缀
interface Strategy {
    /**
     * 判断当前策略是否适用于给定的数据。
     * @param data 用于判断的数据
     * @return 如果适用则返回 true，否则返回 false
     */
    boolean appliesTo(String data);

    /**
     * 执行策略的业务逻辑。
     * @param data 策略执行所需的数据
     */
    void execute(String data);
}

// 具体策略实现 A
@Named // 标记为可被DI容器管理的组件，例如Spring的@Component
class ConcreteStrategyA implements Strategy {
    private Dependency dep; // 策略本身的依赖通过DI注入

    public ConcreteStrategyA(Dependency dep) { // 假设Dependency也是一个DI管理的组件
        this.dep = dep;
    }

    @Override
    public boolean appliesTo(String data) {
        return "typeA".equals(data);
    }

    @Override
    public void execute(String data) {
        System.out.println("Executing Strategy A for: " + data);
        // dep.doSomething(); // 使用注入的依赖
    }
}

// 具体策略实现 B
@Named
class ConcreteStrategyB implements Strategy {
    @Override
    public boolean appliesTo(String data) {
        return "typeB".equals(data);
    }

    @Override
    public void execute(String data) {
        System.out.println("Executing Strategy B for: " + data);
    }
}

// 策略解析器
class StrategyResolver {
    private final List<Strategy> strategies;

    // 构造函数注入所有 Strategy 接口的实现
    public StrategyResolver(List<Strategy> strategies) {
        this.strategies = strategies;
    }

    // ... 解析逻辑将在下一节详述
}

在上述代码中，StrategyResolver 的构造函数接收一个 List。当DI容器初始化 StrategyResolver 时，它会自动查找所有实现 Strategy 接口并被标记为组件（例如，使用 @Named 或 Spring 的 @Component）的类，并将它们的实例收集到一个列表中注入进来。这样，StrategyResolver 无需关心策略的具体实例化过程，也避免了冗长的依赖列表。

2.2 动态选择策略

为了让 StrategyResolver 能够根据输入数据选择正确的策略，我们为 Strategy 接口添加一个 appliesTo 方法。每个具体策略实现这个方法来判断自身是否适用于给定的上下文。

// StrategyResolver 的 resolve 方法
class StrategyResolver {
    private final List<Strategy> strategies;

    public StrategyResolver(List<Strategy> strategies) {
        this.strategies = strategies;
    }

    /**
     * 根据输入数据解析并返回适用的策略。
     * @param data 用于判断策略的数据
     * @return 适用的策略实例
     * @throws IllegalArgumentException 如果没有找到适用的策略
     */
    public Strategy resolve(String data) {
        for (Strategy strategy : strategies) {
            if (strategy.appliesTo(data)) {
                return strategy;
            }
        }
        throw new IllegalArgumentException("No strategy applies to: " + data);
    }

    // 使用 Java 8 Stream API 的更简洁实现
    public Strategy resolveWithStream(String data) {
        return strategies.stream()
                         .filter(s -> s.appliesTo(data))
                         .findFirst() // 或 findAny()，取决于是否需要保证顺序
                         .orElseThrow(() -> new IllegalArgumentException("No strategy applies to: " + data));
    }
}

通过这种方式，StrategyResolver 的 resolve 方法变得非常简洁和通用。它不再需要硬编码的 if-else 逻辑来判断具体类型，而是依赖于策略自身的判断能力。这大大提高了代码的内聚性和可扩展性。当需要添加新的策略时，只需创建新的 Strategy 实现并将其注册为DI组件，StrategyResolver 无需修改。

3. 健壮性考虑与默认策略

在某些情况下，可能需要确保 resolve 方法总能返回一个策略，而不是抛出异常。这时可以引入一个“默认策略”（Default Strategy）。默认策略应该总是返回 true 给 appliesTo 方法，并作为策略列表中的最后一个元素被处理。

@Named
class DefaultStrategy implements Strategy {
    @Override
    public boolean appliesTo(String data) {
        return true; // 默认策略总是适用
    }

    @Override
    public void execute(String data) {
        System.out.println("Executing Default Strategy for: " + data);
        // 可以记录日志或执行默认行为，例如返回一个默认结果
    }
}

class StrategyResolverWithDefault {
    private final List<Strategy> strategies;

    public StrategyResolverWithDefault(List<Strategy> strategies, DefaultStrategy defaultStrategy) {
        // 创建一个可修改的列表，并将默认策略添加到末尾
        List<Strategy> allStrategies = new ArrayList<>(strategies);
        allStrategies.add(defaultStrategy); // 确保默认策略在最后被检查
        this.strategies = allStrategies;
    }

    public Strategy resolve(String data) {
        // 这里的解析逻辑与之前相同，因为默认策略总能匹配，所以不会抛出异常
        return strategies.stream()
                         .filter(s -> s.appliesTo(data))
                         .findFirst()
                         .orElseThrow(() -> new IllegalStateException("Default strategy should always apply, this indicates a configuration error.")); // 理论上不会发生
    }
}

通过注入 DefaultStrategy 并将其添加到策略列表的末尾，可以确保当没有其他特定策略匹配时，默认策略将始终被选中。这提供了一种优雅的方式来处理未预期或通用的情况，避免了客户端代码中的空指针或异常处理。

4. 总结与最佳实践

通过上述方法，我们成功地在策略模式中避免了服务定位器这一反模式，并充分利用了依赖注入的优势：

• 解耦性增强： StrategyResolver 不再直接依赖具体的策略实现，而是依赖于 Strategy 接口的集合。这符合依赖倒置原则。
• 可测试性提升： 策略和解析器都更容易进行单元测试，因为它们的依赖都可以通过DI容器或手动模拟轻松提供。
• 可扩展性良好： 添加新策略时，只需创建新的实现类并将其注册到DI容器，无需修改 StrategyResolver。这符合开闭原则。
• 代码简洁性： StrategyResolver 的逻辑变得简洁，专注于遍历和选择，而不是复杂的条件判断和对象创建。

在实际开发中，应始终优先考虑使用依赖注入来管理组件及其依赖，避免服务定位器模式，以构建更健壮、可维护和可扩展的应用程序。同时，合理命名接口（如 Strategy 而不是 StrategyInterface）也是提升代码可读性的良好实践。

好了，本文到此结束，带大家了解了《策略模式替代服务定位器：依赖注入更优雅》，希望本文对你有所帮助！关注golang学习网公众号，给大家分享更多文章知识！