【问题标题】:Inject Util Class with Google Guice vs static Methods?使用 Google Guice 与静态方法注入 Util 类?
【发布时间】:2010-12-06 20:33:44
【问题描述】:

我想知道用 google guice 注入实用程序方法是否是一种好风格。

假设我们有一个转换器实用程序类:

public class UtilClass
{
  public static Result convert(Source src)
  {
    //Do conversion

    return result;
  }
}

我的想法是使用 guice 像这样将这个实用程序作为 Singleton 注入

@Singleton
public class UtilClass
{
  public Result convert(Source src)
  {
    //Do conversion

    return result;
  }
}

对于使用 guice 构建的应用程序推荐哪种方式?

【问题讨论】:

    标签: java static dependency-injection guice


    【解决方案1】:

    这取决于您的 convert() 方法的性质。

    如果有的话

    • 简单
    • 确定性(即不依赖于其他参数)
    • 没有副作用
    • 不太可能改变

    您可以将其保留为静态实用程序方法。

    否则它是一个很好的依赖注入候选者(您可以将其重命名为ConversionService 以使其更清晰)。

    【讨论】:

      【解决方案2】:

      首先,您注入此实用程序类的实例而不是继续使用您拥有的静态方法的目标是什么?具有输入和输出且没有副作用的函数通常最好作为静态方法。也就是说,也许您希望能够更改此方法用于测试或类似的功能。在这种情况下,您通常希望该类实现您在客户端类中使用的某个接口。

      无论如何,如果UtilClass 是无状态的,我会而不是将它作为单例注入。注入非单例比注入单例更快。也许如果您要将注入的实例存储在许多其他类中,单例可能对节省空间有意义。

      【讨论】:

      • 感谢您澄清单例注入问题!
      【解决方案3】:

      就我个人而言,我通常尽量不让我的应用程序使用依赖注入框架连接的事实影响我为我的类等做出的设计决策。良好的设计实践应该规定这一点。在您的情况下,您的实用程序类似乎不依赖于状态,因此保持静态似乎是一个明智的选择。

      无论如何,您的实用程序类不是任何接口的实现,因此使用它的客户端代码仍然具有紧密耦合的依赖关系。有了这个,就很难看出使用 DI 注入实用程序类有什么好处,而不是直接在客户端代码中引用静态类。

      【讨论】: