您的位置: 首页 > 技术专栏

Java高效编程:固定资源首选使用依赖注入

来源:  |  发布时间:2021-08-25  |  浏览量:87

许多类依赖于一个或多个底层资源。例如,拼写检查器依赖于字典。常见的做法是将这些类实现为静态实用程序类(第 4 项):

// Inappropriate use of static utility - inflexible & untestable!public class SpellChecker {    private static final Lexicon dictionary = ...;    private SpellChecker() {} // Noninstantiable    public static boolean isValid(String word) { ... }    public static List<String> suggestions(String typo) { ... }}

  同样的,将它们作为单例实现的情况并不少见(第 3 项):

// Inappropriate use of singleton - inflexible & untestable!public class SpellChecker {    private final Lexicon dictionary = ...;    private SpellChecker(...) {}    public static INSTANCE = new SpellChecker(...);    public boolean isValid(String word) { ... }    public List<String> suggestions(String typo) { ... }}

  这些方法都不令人满意,因为它们假设只有一本值得使用的字典。在实践中,每种语言都有自己的字典,特殊字典用于特殊词汇。而且,可能需要使用特殊字典进行测试。假设单本字典就足以满足所有情况,这是一厢情愿的想法。

  你可以尝试让 SpellChecker 支持多个词典,方法是使字典字段为非 final 域,并添加一个方法来更改现有拼写检查器中的字典,但这在并发时设置会很笨拙,容易出错并且不可行。静态实用程序类和单例不适用于将底层资源作为参数的类(Static utility classes and singletons are inappropriate for classes whose behavior is parameterized by an underlying resource.)。

  所需要的是能够支持类的多个实例(在我们的示例中为 SpellChecker),每个实例都使用客户端所需的资源(在我们的示例中为字典)。满足此要求的简单模式是在创建新实例时将资源传递给构造函数。这是依赖注入的一种形式:字典是拼写检查器的依赖项,并在创建时注入拼写检查器。

// Dependency injection provides flexibility and testabilitypublic class SpellChecker {    private final Lexicon dictionary;    public SpellChecker(Lexicon dictionary) {        this.dictionary = Objects.requireNonNull(dictionary);    }    public boolean isValid(String word) { ... }    public List<String> suggestions(String typo) { ... }}

  这种依赖注入很简单,以至于程序猿用了很多年却不知道它有一个名称。虽然我们的拼写检查器只有一个资源(字典),但是依赖注入可以使用任意数量的资源和任意的依赖关系,它保留了不变性(第 17 项),因此多个客户端可以共享依赖对象(假设客户端需要相同的底层资源)。依赖注入同样适用于构造函数、静态工厂(第 1 项)和构建器(第 2 项)。

  将资源工厂传递给构造函数就会变成一个有用的模式。工厂是一个对象,通过重复调用这个工厂可以创建某个类型的实例对象。这些就是工厂方法模式 [Gamma95]。Java 8 中引入的 Supplier<T>;接口非常适合体现工厂。在输入上采用 Supplier<T>的方法通常应该使用泛型(第 31 项)约束工厂的类型参数,以允许客户端传入创建指定类型的任何子类型的工厂。例如,这是一种使用客户提供的工厂生成马赛克来生成每个图块的方法:

Mosaic create(Supplier<? extends Tile> tileFactory) { ... }

  尽管依赖注入极大地提高了灵活性和可测试性,但它可能会使大型项目更加混乱,这些项目通常包含数千个依赖项。通过使用依赖注入框架,例如 Dagger [Dagger],Guice [Guice]或 Spring [Spring],可以消除这种混乱。这些框架的使用超出了本书的范围,但请注意,为手动依赖注入而设计的 API 可以轻松地适用于这些框架。

  总之,如果有一个类依赖一个或多个底层资源的类,并且底层资源类影响了类的行为,不要使用单例或静态实用程序类来实现它,并且不要让类直接创建这些资源(do not use a singleton or static utility class to implement a class that depends on one or more underlying resources whose behavior affects that of the class)。相反,将资源或工厂传递给构造函数(或静态工厂或构建器)。这种做法称为依赖注入,将极大地增强类的灵活性,可重用性和可测试性。


    相关新闻

    24小时报名热线

    400-7777-699

    报名热线:400-7777-699

    微博

    微信公众号

    友情链接 :智原在线   美味学院   安徽新华电脑   安徽新华教育

    华信智原(官网)|京ICP备09028087号-8|咨询热线:400-7777-699|地址:北京海淀区北三环中路44号院爱工场文化教育产业园|版权所有:北京华信智原教育技术有限公司
    在线报名 学费详情 开班信息 职业护航 视频下载

    小小华想和您聊一聊