假设我有一个实用程序类 DateUtil (见下文)。使用此方法 调用者方法使用 DateUtils.getDateAsString(aDate)。去掉会不会更好 static 修饰符并使 DateUtil 成为 spring bean(请参阅 DateUtilsBean)并将其注入到调用类中 或者就保持原样?
我看到使用静态的一个缺点是模拟问题,请参阅如何使用静态方法进行模拟?
public class DateUtils {
public static String getDateAsString(Date date) {
String retValue = "" // do something here using date parameter
return retValue;
}
}
Spring Bean 版本
@Component
public class DateUtilsBean {
public String getDateAsString(Date date) {
String retValue = "" // do something here using date parameter
return retValue;
}
}
我不这么认为。 DateUtils 类听起来像是一个纯粹的实用程序类,没有任何副作用,只是处理输入参数。这种功能也可以保留在静态方法中。我认为您不太可能想要模拟日期帮助器方法。
我同意肖恩·帕特里克·弗洛伊德的观点。
这是我的标准:如果类的方法仅通过它们接收的参数执行操作,没有外部依赖项(数据库、文件系统、用户配置、其他对象/bean 等),那么我会使用 static方法,通常在具有私有构造函数的最终类中。
否则,我会使用 Spring bean 来实现它。
所以,如果你提出的话,根据这个标准,我会编写一个带有静态方法的类。
问候。
最好将其声明为Spring bean,因为它的生命周期由Spring管理,最终您可以注入依赖项,池化对象,以及以适当的方式测试它,更不用说您了可以将它用作常规对象并将其作为参数传递,在子类中重新定义方法...等等。
简而言之,是的,在大多数情况下这将是一个更好的设计。然而,在像暴露这样简单的情况下,它并没有太大的区别。
此评论中有一个很好的答案我应该在 Spring 单例 bean 中使用静态吗
静态变量在一个 JVM 中有一个实例。每个 Spring 上下文都存在单例。如果您的应用程序只有一个上下文,它们会执行相同的工作。
但不要将它们混合在一起。在一些旧项目中,我看到一些不纯的实用程序类通过 ApplicationContext 使用一些 spring bean。为它编写测试用例非常困难。
虽然这里大多数人支持使用带有静态方法的 Util 类而不是 Spring beans,但我反对。
相反 - 使用具有静态方法的 util 类是众所周知的设计问题,称为“紧耦合”,它会导致“代码脆弱性”。 考虑这样一种情况,您有一个带有静态方法的实用程序类。在某些时候,您需要根据新功能的请求添加注入的依赖项。突然之间,它不再是 Util,而是 UtilBean。因此,您不必向原始 Util 添加方法,而是必须重命名它并重构调用它的所有代码。重构很便宜,对吗?如果您正在构建一个在其他应用程序中使用的库并且您无法控制它们,那么速度就不会那么快。你猜怎么着?你怎么知道你今天的代码明天不是编译的库依赖项?
MVC 架构
设计。在这种情况下,Util 类在哪里?它听起来像一个服务,但它似乎是不同的东西,并且可能会有一个单独的包。不太好。这是我关于该问题的文章https://medium.com/@pavlomorozov78/static-methods-in-spring-utility-classes-9994ae6aa949