本文探讨了在策略模式中避免使用服务定位器这一反模式的有效方法。当存在大量策略且每个策略都有复杂依赖时，传统的服务定位器或手动注入会导致代码臃肿和维护困难。教程将详细介绍如何利用依赖注入框架（如Spring）自动收集策略列表，并通过在策略接口中定义判断方法来动态选择合适的策略，从而实现更简洁、可测试且符合DI原则的解决方案。
策略模式与服务定位器的问题
策略模式（strategy pattern）是一种行为设计模式，它允许在运行时选择算法的行为。通常，我们会定义一个策略接口，并由多个具体策略类实现该接口，每个类封装一种特定的算法。一个策略解析器（strategy resolver）负责根据特定条件选择并执行正确的策略。
然而，在实现策略解析器时，一个常见的陷阱是引入服务定位器（Service Locator）模式。服务定位器被认为是一种反模式，因为它隐藏了依赖关系，增加了系统的复杂性和测试难度。考虑以下伪代码示例：
// 策略接口
interface StrategyInterface {
void execute();
}
// 具体策略A, B, C，它们可能有各自的依赖
class A implements StrategyInterface {
private Dependency dep;
public A(Dependency dep) {
this.dep = dep;
}
@Override
public void execute() { /* ... */ }
}
class B implements StrategyInterface {
private AnotherDependency anotherDep;
public B(AnotherDependency anotherDep) {
this.anotherDep = anotherDep;
}
@Override
public void execute() { /* ... */ }
}
// ... 更多策略
// 使用服务定位器的策略解析器
class StrategyResolver {
private ServiceLocator locator; // 服务定位器
public StrategyResolver(ServiceLocator locator) {
this.locator = locator;
}
public StrategyInterface resolve(String data) {
if ("conditionX".equals(data)) {
return locator.get(A.class); // 通过服务定位器获取策略实例
} else if ("conditionY".equals(data)) {
return locator.get(B.class);
}
return locator.get(C.class);
}
}
上述代码中，StrategyResolver 通过 ServiceLocator 获取具体的策略实例。虽然这解决了策略类 A, B, C 可能具有不同依赖的问题，但 ServiceLocator 的引入使得 StrategyResolver 与容器紧密耦合，并且其依赖不再显式。如果策略数量增加到十个甚至更多，if-else if 链会变得冗长，且 StrategyResolver 的职责变得复杂。
基于依赖注入的策略模式优化
为了避免服务定位器并保持代码的清晰和可测试性，我们可以利用现代依赖注入（DI）框架（如Spring）的特性。核心思想是让DI容器自动收集所有实现了特定策略接口的实例，并将它们注入到策略解析器中。
1. 策略接口与可判断性
首先，我们可以优化策略接口的命名，移除冗余的 “Interface” 后缀，使其更简洁。更重要的是，为策略接口添加一个方法，用于判断当前策略是否适用于给定的上下文数据。
// 策略接口
public interface Strategy {
/**
* 判断当前策略是否适用于给定的数据
* @param data 上下文数据
* @return 如果适用则返回 true，否则返回 false
*/
boolean appliesTo(String data);
/**
* 执行策略的具体逻辑
*/
void execute();
}
2. 具体策略实现
每个具体策略类需要实现 Strategy 接口，并提供其 appliesTo 方法的实现，以声明其适用条件。同时，它们可以继续通过构造函数注入自身的依赖。为了让DI容器能够发现这些策略，需要使用相应的注解（如Spring的 @Component 或 @Named）。
import javax.inject.Named; // 或者 org.springframework.stereotype.Component
@Named // 或者 @Component
public class ConcreteStrategyA implements Strategy {
private SomeDependency dependencyA;
public ConcreteStrategyA(SomeDependency dependencyA) {
this.dependencyA = dependencyA;
}
@Override
public boolean appliesTo(String data) {
// 示例：如果数据是 "typeA"，则此策略适用
return "typeA".equals(data);
}
@Override
public void execute() {
System.out.println("Executing ConcreteStrategyA with dependency: " + dependencyA.getName());
}
}
@Named // 或者 @Component
public class ConcreteStrategyB implements Strategy {
private AnotherDependency dependencyB;
public ConcreteStrategyB(AnotherDependency dependencyB) {
this.dependencyB = dependencyB;
}
@Override
public boolean appliesTo(String data) {
// 示例：如果数据是 "typeB"，则此策略适用
return "typeB".equals(data);
}
@Override
public void execute() {
System.out.println("Executing ConcreteStrategyB with dependency: " + dependencyB.getDescription());
}
}
// ... 更多策略
3. 策略解析器的实现
在策略解析器中，我们可以通过构造函数注入一个 List<Strategy>。Spring等DI框架会自动收集所有实现了 Strategy 接口并被容器管理的Bean，并将它们注入到这个列表中。这样，StrategyResolver 的依赖列表就不会随着策略数量的增加而变得过长。
import java.util.List;
import java.util.stream.Collectors;
import javax.inject.Named; // 或者 org.springframework.stereotype.Component
@Named // 或者 @Component
public class StrategyResolver {
private final List<Strategy> strategies;
// Spring 会自动注入所有实现了 Strategy 接口的 Bean
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: " + data);
}
// 使用 Java 8 Stream API 的更简洁写法
public Strategy resolveWithStream(String data) {
return strategies.stream()
.filter(strategy -> strategy.appliesTo(data))
.findFirst() // 或者 findAny()，取决于是否需要特定顺序
.orElseThrow(() -> new IllegalArgumentException("No strategy applies to data: " + data));
}
}
4. 处理无匹配策略和默认策略
在 resolve 方法中，如果没有任何策略适用，我们抛出了 IllegalArgumentException。在某些场景下，我们可能不希望抛出异常，而是提供一个默认行为。这可以通过引入一个“默认策略”来实现：
import java.util.ArrayList;
import java.util.List;
import javax.inject.Named; // 或者 org.springframework.stereotype.Component
@Named // 或者 @Component
public class DefaultStrategy implements Strategy {
@Override
public boolean appliesTo(String data) {
return true; // 默认策略总是适用
}
@Override
public void execute() {
System.out.println("Executing DefaultStrategy: No specific strategy found.");
}
}
@Named // 或者 @Component
public class StrategyResolverWithDefault {
private final List<Strategy> strategies;
// 注入所有策略和默认策略
public StrategyResolverWithDefault(List<Strategy> strategies, DefaultStrategy defaultStrategy) {
// 创建一个新的列表，将所有具体策略添加进去
this.strategies = new ArrayList<>(strategies);
// 将默认策略添加到列表的末尾，确保它在所有其他策略之后被检查
this.strategies.add(defaultStrategy);
}
public Strategy resolve(String data) {
return strategies.stream()
.filter(strategy -> strategy.appliesTo(data))
.findFirst()
.orElseThrow(() -> new IllegalStateException("This should not happen if DefaultStrategy is present."));
// 如果DefaultStrategy被正确添加，这里永远不会抛出异常
}
}
通过将 DefaultStrategy 添加到策略列表的末尾，我们可以确保它只有在所有其他具体策略都不适用时才会被选中，从而提供一个优雅的降级方案。
总结
通过上述方法，我们成功地在策略模式中避免了服务定位器这一反模式。这种基于依赖注入的实现方式带来了诸多优势：
- 解耦性强： StrategyResolver 不再依赖于具体的DI容器实现，而是依赖于 List<Strategy> 接口，提高了模块间的解耦。
- 可测试性高： StrategyResolver 可以轻松地通过模拟（Mock）List<Strategy> 进行单元测试，无需启动完整的DI容器。
- 扩展性好： 增加新的策略时，只需创建新的策略类并实现 Strategy 接口，DI容器会自动发现并将其注入到 StrategyResolver 中，无需修改现有代码（遵循开闭原则）。
- 代码简洁： StrategyResolver 的构造函数和 resolve 方法保持简洁，避免了冗长的条件判断和手动实例化逻辑。
这种模式在处理大量策略且每个策略都有自身复杂依赖的场景下尤其有效，它提供了一种优雅、可维护且符合现代软件设计原则的解决方案。
以上就是避免在策略模式中使用服务定位器：基于依赖注入的优雅实现的详细内容，更多请关注php中文网其它相关文章！