
策略模式(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 链会变得冗长且难以管理。
为了避免服务定位器带来的问题,我们可以充分利用现代依赖注入(DI)框架(如Spring、Guice等)的强大功能。核心思想是让DI容器自动收集所有实现了特定接口的策略,并将它们作为一个集合注入到策略解析器中。
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 无需关心策略的具体实例化过程,也避免了冗长的依赖列表。
为了让 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 无需修改。
在某些情况下,可能需要确保 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 并将其添加到策略列表的末尾,可以确保当没有其他特定策略匹配时,默认策略将始终被选中。这提供了一种优雅的方式来处理未预期或通用的情况,避免了客户端代码中的空指针或异常处理。
通过上述方法,我们成功地在策略模式中避免了服务定位器这一反模式,并充分利用了依赖注入的优势:
在实际开发中,应始终优先考虑使用依赖注入来管理组件及其依赖,避免服务定位器模式,以构建更健壮、可维护和可扩展的应用程序。同时,合理命名接口(如 Strategy 而不是 StrategyInterface)也是提升代码可读性的良好实践。
以上就是策略模式中避免服务定位器:基于依赖注入的优雅实现的详细内容,更多请关注php中文网其它相关文章!
每个人都需要一台速度更快、更稳定的 PC。随着时间的推移,垃圾文件、旧注册表数据和不必要的后台进程会占用资源并降低性能。幸运的是,许多工具可以让 Windows 保持平稳运行。
Copyright 2014-2025 https://www.php.cn/ All Rights Reserved | php.cn | 湘ICP备2023035733号