在 Spring 应用程序中的实用工具类——我是否应该使用静态方法？

假设我有一个实用工具类 DateUtil (参见下面) 调用方法使用 DateUtils.getDateAsString (aDate) 静态修饰符，使 DateUtil 成为一个弹簧 bean (参见 DateUtilsBean) ，并将其注入到调用类中 还是就让它这样？

我可以看到使用静态的一个缺点是关于嘲讽的问题，请参阅 如何使用静态方法进行模拟？

public class DateUtils {


public static String getDateAsString(Date date) {
String retValue =  "" // do something here using date parameter
return retValue;
}
}

春豆的版本

@Component
public class DateUtilsBean {


public String getDateAsString(Date date) {
String retValue =  "" // do something here using date parameter
return retValue;
}
}
54071 次浏览
小开
最佳答案

我不这么认为。DateUtils 类听起来像是一个纯粹的实用工具类，它没有任何副作用，只是处理输入参数。这种功能最好保留在静态方法中。我认为您不太可能想要模拟日期帮助器方法。

小开

最好将它声明为 Spring bean，因为它的生命周期是由 Spring 管理的，你可以最终注入依赖项，池对象，以及以适当的方式测试它，而不是说你可以将它作为一个常规对象使用，并将它作为参数传递，在子类中重新定义方法等等。

简而言之，是的，在大多数情况下，这将是一个更好的设计。然而，在一个像曝光这样简单的情况下，它并没有起到很大的作用。

小开

我同意 Sean Patrick Floyd 的观点。

这就是我的标准: 如果类的方法只对它们接收到的参数执行操作，没有外部依赖关系(数据库、文件系统、用户配置、其他对象/bean 等) ，那么我将使用静态方法执行操作，通常在最终的类中使用私有构造函数。

否则，我将使用 Springbean 实现它。

因此，在您引发的情况下，根据这个条件，我将编写一个具有静态方法的类。

问候。

小开

一个很好的答案在这个评论 我是否应该在春天使用静电豆

静态变量在一个 JVM 中有一个实例。每个春季上下文存在一个单例。如果应用程序只有一个上下文，则它们执行相同的工作。

但不要把它们混在一起。在一些老项目中，我看到一些非纯实用工具类通过 ApplicationContext 使用一些 spring bean。为它编写测试用例是非常困难的。


提交答案