Java高效编程（5）：优先使用依赖注入而非硬编码资源

解锁Python编程的无限可能：《奇妙的Python》带你漫游代码世界

在软件开发中，许多类依赖于某些底层资源。例如，一个拼写检查器类可能依赖于一个词典资源。这种类通常会被错误地实现为静态工具类或单例类，导致不灵活且难以测试。常见的例子是将这些资源硬编码在类内部，这种做法的主要问题在于它假设只有一个固定的资源可供使用，忽视了实际情况中的多样性需求，例如不同语言或特殊领域的词典。

静态工具类和单例类的局限性

首先，考虑静态工具类的实现方式：

// 静态工具类的错误使用 - 不灵活且难以测试！
public class SpellChecker {
    private static final Dictionary dictionary = new Dictionary();
    private SpellChecker() {} // 防止实例化

    public static boolean isValid(String word) {
        // 校验单词
        return true;
    }

    public static List<String> suggestions(String typo) {
        // 提供拼写建议
        return List.of("建议1", "建议2");
    }
}

这种设计将词典资源固定在了类内部，难以适应多种词典需求，例如不同语言或领域的专用词典。并且它不允许使用模拟词典来进行测试，导致测试的灵活性受限。

类似地，单例模式也存在类似问题：

// 单例模式的错误使用 - 不灵活且难以测试！
public class SpellChecker {
    private final Dictionary dictionary;
    private static final SpellChecker INSTANCE = new SpellChecker(new Dictionary());

    private SpellChecker(Dictionary dictionary) {
        this.dictionary = dictionary;
    }

    public static SpellChecker getInstance() {
        return INSTANCE;
    }

    public boolean isValid(String word) {
        return true;
    }

    public List<String> suggestions(String typo) {
        return List.of("建议1", "建议2");
    }
}

单例模式同样假设只有一个词典，无法灵活切换，也难以使用不同的词典进行测试。这种设计不适合行为依赖于底层资源的类。

依赖注入的灵活性

为了解决上述问题，我们可以通过依赖注入的方式将资源传递给类的构造函数，使其更加灵活且易于测试。依赖注入是一种将类所需的资源作为参数传递到构造函数中的设计模式。如下所示：

// 使用依赖注入实现灵活性和可测试性
public class SpellChecker {
    private final Dictionary dictionary;

    public SpellChecker(Dictionary dictionary) {
        this.dictionary = Objects.requireNonNull(dictionary);
    }

    public boolean isValid(String word) {
        // 根据提供的词典检查单词
        return true;
    }

    public List<String> suggestions(String typo) {
        // 根据提供的词典提供建议
        return List.of("建议1", "建议2");
    }
}

通过这种方式，我们在实例化 SpellChecker 时可以灵活地传入不同的词典，如英语词典、法语词典，或甚至用于测试的模拟词典。依赖注入不仅提高了代码的可重用性，还保证了类的不可变性，因为资源是通过构造函数传入的，保证了对象一旦创建后其依赖的资源不会发生变化。

依赖注入与工厂模式

在某些情况下，我们可能希望动态创建资源，而不是直接传递资源实例。此时，我们可以将资源工厂传递给构造函数。工厂是一种可以重复调用以创建资源实例的对象。这种模式称为工厂方法模式，可以使用 Java 8 引入的 Supplier<T> 接口来表示工厂。例如，我们可以创建一个马赛克，并使用客户端提供的工厂生成每个图块：

public class Mosaic {
    public static Mosaic create(Supplier<? extends Tile> tileFactory) {
        // 使用工厂生成图块并创建马赛克
        return new Mosaic();
    }
}

通过传递工厂，我们能够在不同的环境下灵活生成所需的资源。这种模式允许更复杂的依赖图，并且通过 Supplier<T> 接口，可以让方法接受任意类型的子类型工厂，从而增加灵活性。

依赖注入框架

在较大的项目中，通常会有大量的依赖项，手动进行依赖注入可能会显得繁琐。在这种情况下，我们可以使用依赖注入框架（如 Dagger、Guice 或 Spring）来自动管理依赖关系。尽管这些框架超出了本书的范围，但值得注意的是，使用这些框架时，依赖注入的 API 很容易适应它们，框架可以帮助我们自动处理大量的依赖关系，减少代码复杂性。

总结

不要使用单例或静态工具类来实现依赖于底层资源的类，尤其当这些资源会影响类的行为时。也不要让类直接创建其所依赖的资源。相反，应当通过构造函数、静态工厂或构建器传递资源或资源工厂，这种实践称为依赖注入。依赖注入不仅能大幅提高类的灵活性、可重用性和可测试性，还能有效减少代码中的硬编码资源依赖，提升代码的维护性。

---