本教程探讨如何在策略设计模式中避免使用服务定位器（Service Locator）这一反模式。通过利用依赖注入（DI）容器自动收集策略实现，并结合策略接口的自判断机制，实现一个简洁、可维护且符合DI原则的策略解析器，从而提升代码质量和可测试性。
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<Strategyyoujiankuohaophpcn。当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）也是提升代码可读性的良好实践。