避免服务定位器：依赖注入优雅实现指南

策略模式与服务定位器反模式

策略模式（Strategy Pattern）是一种行为设计模式，它允许在运行时选择算法或行为。通常，我们定义一个策略接口，然后有多个具体的策略实现。一个策略上下文或解析器负责根据特定条件选择并执行合适的策略。

然而，在实现策略选择逻辑时，一个常见的陷阱是使用服务定位器（Service Locator）。服务定位器是一种反模式，因为它引入了对具体定位器实现的强耦合，使得代码难以测试和维护。当策略本身具有复杂的依赖关系，并且存在大量策略实现时，问题尤为突出。

考虑以下使用服务定位器的伪代码示例：

// 策略接口及其实现
interface Strategy {
    void execute();
}

class ConcreteStrategyA implements Strategy {
    private Dependency dep;
    constructor(Dependency dep) { this.dep = dep; }
    void execute() { /* ... */ }
}
// ConcreteStrategyB, ConcreteStrategyC 类似

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

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

    public function resolveAndExecute(data): Strategy {
        if (conditionX(data)) {
            return locator->get(ConcreteStrategyA);
        } else if (conditionY(data)) {
            return locator->get(ConcreteStrategyB);
        }
        return locator->get(ConcreteStrategyC);
    }
}

上述代码中，StrategyResolver 直接依赖于 ServiceLocator，并需要知道具体的策略类名来获取实例。这不仅增加了耦合，也使得 StrategyResolver 难以独立测试。如果策略数量增多，if-else if 链会变得冗长且难以管理。

基于依赖注入的解决方案

为了避免服务定位器，我们可以利用现代依赖注入（DI）框架（如Spring、Guice等）的强大功能。核心思想是让DI容器自动发现并注入所有实现了特定策略接口的类，而不是由解析器主动去“拉取”它们。

1. 自动注入所有策略实现

DI框架能够识别并收集某一特定接口的所有实现类。以Spring为例，我们可以通过构造函数注入一个 List 集合，其中包含所有实现了 Strategy 接口的Bean。

首先，定义策略接口：

public interface Strategy {
    // 策略的业务方法
    void execute();
    // 用于判断当前策略是否适用
    boolean appliesTo(String data);
}

然后，实现具体的策略。这些策略类需要被DI容器管理，例如在Spring中可以使用 @Component 或 @Named 注解：

import org.springframework.stereotype.Component; // 或 javax.inject.Named

@Component // 或 @Named
public class ConcreteStrategyA implements Strategy {
    private final SomeDependency dep;

    public ConcreteStrategyA(SomeDependency dep) {
        this.dep = dep;
    }

    @Override
    public void execute() {
        System.out.println("Executing Strategy A with dependency: " + dep.getName());
    }

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

@Component // 或 @Named
public class ConcreteStrategyB implements Strategy {
    // ... 类似的依赖注入和实现
    @Override
    public void execute() {
        System.out.println("Executing Strategy B");
    }

    @Override
    public boolean appliesTo(String data) {
        return "typeB".equals(data);
    }
}
// 更多策略实现...

接下来，策略解析器 StrategyResolver 可以通过构造函数直接注入所有 Strategy 接口的实现：

import org.springframework.stereotype.Component;
import java.util.List;
import java.util.Optional;

@Component
public class StrategyResolver {
    private final List strategies;

    // Spring 会自动收集所有实现了 Strategy 接口的 Bean 并注入到此列表中
    public StrategyResolver(List strategies) {
        this.strategies = strategies;
    }

    // ... 策略解析逻辑
}

通过这种方式，StrategyResolver 不再关心策略的具体实现类，也不需要服务定位器。它只知道一个 Strategy 列表，极大地降低了耦合度。

2. 策略的动态选择与执行

为了在运行时选择正确的策略，我们需要在 Strategy 接口中添加一个判断方法，例如 appliesTo(data)。每个具体策略根据自身的业务逻辑实现这个方法，判断它是否适用于给定的输入数据。

StrategyResolver 的 resolve 方法将遍历注入的策略列表，找到第一个 appliesTo 返回 true 的策略并返回。

import org.springframework.stereotype.Component;
import java.util.List;
import java.util.Optional;

@Component
public class StrategyResolver {
    private final List strategies;

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

    public Strategy resolve(String data) {
        // 使用传统循环方式
        for (Strategy strategy : strategies) {
            if (strategy.appliesTo(data)) {
                return strategy;
            }
        }
        // 或者使用 Java 8 Stream API
        return strategies.stream()
                .filter(strategy -> strategy.appliesTo(data))
                .findFirst() // 找到第一个匹配的策略
                .orElseThrow(() -> new IllegalArgumentException("No strategy applies to data: " + data));
    }

    public void executeStrategy(String data) {
        Strategy strategy = resolve(data);
        strategy.execute();
    }
}

健壮性考量：无匹配策略的处理

在实际应用中，可能会出现没有任何策略适用于给定输入数据的情况。为了增强系统的健壮性，我们可以采取以下两种策略：

1. 抛出异常: 如上例所示，如果找不到匹配的策略，可以抛出 IllegalArgumentException 或自定义异常，明确告知调用方当前数据无法处理。
2. 提供默认策略: 创建一个“默认策略”(DefaultStrategy)，它在 appliesTo() 方法中始终返回 true。确保这个默认策略在DI容器注入的列表中是最后一个被考虑的（例如，通过在 StrategyResolver 构造函数中显式添加到列表末尾，或者通过Spring的 @Order 注解）。

// DefaultStrategy 实现
@Component
public class DefaultStrategy implements Strategy {
    @Override
    public void execute() {
        System.out.println("Executing Default Strategy (no specific strategy applied).");
    }

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

// StrategyResolver 构造函数中处理默认策略
@Component
public class StrategyResolver {
    private final List strategies;

    public StrategyResolver(List injectedStrategies, DefaultStrategy defaultStrategy) {
        // 创建一个新的列表，将默认策略添加到末尾
        this.strategies = new java.util.ArrayList<>(injectedStrategies);
        this.strategies.add(defaultStrategy);
        // 注意：Spring注入的List默认是不可修改的，需要复制
    }

    public Strategy resolve(String data) {
        // Stream API 同样适用，DefaultStrategy 会作为最后一个被考虑
        return strategies.stream()
                .filter(strategy -> strategy.appliesTo(data))
                .findFirst()
                .get(); // 因为有DefaultStrategy，所以不会抛出 NoSuchElementException
    }
}

通过这种方式，无论输入数据如何，系统总能找到一个策略来处理，从而避免运行时错误。

最佳实践与总结

• 接口命名: 建议将策略接口直接命名为 Strategy，而不是 StrategyInterface。接口后缀通常是冗余的，因为类型本身已经表明它是一个接口。
• 解耦: 这种基于依赖注入的方法将策略的选择逻辑与策略的具体实现及其依赖完全解耦。StrategyResolver 不再关心如何创建策略实例，也不需要知道所有策略的具体类型。
• 可扩展性: 当需要添加新的策略时，只需创建新的 Strategy 实现类并将其注册为DI容器的Bean，无需修改 StrategyResolver 的代码（开放-封闭原则）。
• 可测试性: StrategyResolver 可以很容易地通过模拟（mock）List 进行单元测试，而无需启动整个DI容器。
• 配置集中: 策略的生命周期和依赖管理由DI容器统一处理，简化了配置和维护。

通过采纳这些实践，我们可以在策略设计模式中有效地避免服务定位器反模式，构建出更加健壮、灵活且易于维护的应用程序。