在什么情况下静态方法是一个好习惯？

Question

我看过以下讨论:

如果私有辅助方法可以是静态的,那么它们应该是静态的吗？如果它们的类没有成员变量,
那么所有方法都应该是静态的

似乎人们通常会接受静态方法,但对此有点怀疑,原因如下:

1. 他们很难测试.
2. 他们违反了OO原则.(一个人说,它们是功能,而不是方法.)

最可接受的静态方法是私有静态方法.但那么为什么存在静态方法,在什么情况下它们是首先被采用的？

Answer 1

静态方法并不难测试.问题是调用静态方法的其他代码很难测试,因为你无法替换静态方法.

我认为静态的方法都很好既可以当它们是私有的或当他们是"实用"的方法-例如,做串逃跑.当您希望能够在测试中模拟或替换的东西使用静态方法时,问题就出现了.工厂方法也很有用,虽然依赖注入通常是一种更好的方法 - 再次,它部分取决于您是否希望能够替换测试中的功能.

至于不是"OO" - 不是你用一般的OO语言写的所有内容都必须是"纯粹的"OO.有时非OO路线更加实用,导致代码更简单.Eric Lippert有一篇很棒的博客文章,遗憾的是我现在找不到.但是,这篇文章中的评论是相关的.它讨论的是扩展方法而不是静态方法,但原理是相同的.

扩展方法经常被批评为"不够OOP".在我看来,这是把车放在马前.OOP的目的是为大型软件项目的结构提供指导,这些项目由不需要了解彼此工作内部细节的人员编写,以提高工作效率.C#的目的是成为一种有用的编程语言,使我们的客户能够在我们的平台上高效工作.显然,OOP既有用又受欢迎,因此我们试图在C#中以OOP方式编写代码.但是C#的目的不是"成为OOP语言".我们根据它们是否对我们的客户有用来评估特征,而不是基于它们是否严格符合某些语言面向对象的抽象学术理想.我们很乐意从oo,功能,程序,命令,声明等方面获取想法,只要我们能够制造出有益于我们客户的一致,有用的产品.

Answer 2

我会说静态方法在它们是函数时肯定是可以的,即它们不做任何IO,没有任何内部状态,只使用它们的参数来计算它们的返回值.

我还将它扩展到改变其参数状态的方法,但如果这样做过度,静态方法应该正确地是它主要操作的参数类的实例方法.

Answer 3

想一想这一点.在OO编码中,每个函数调用实际上都是这样的:

method(object this, object arg1, object arg2)这是你要调用的对象.它真的就是语法糖.此外,它允许您清楚地定义变量的范围,因为您有对象变量等.

静态方法根本没有"this"参数.即你传入变量并可能得到一个结果.1.)是人们避开它们的主要原因,你不能创建静态方法的接口(还),所以你不能模拟静态方法来测试它.

其次OO是程序函数等.静态方法在某些情况下很有意义,但它们总是可以成为对象的方法.

请注意,你不能在没有黑客的情况下删除它:

static void Main(string[] args)
{
}

启动应用程序的代码必须是可调用的,不带对象的引用.因此,它们为您提供了灵活性,无论您选择在您的方案中使用它们都将根据您的要求进行预测.

Answer 4

在单例模式提供太多灵活性的大多数情况下，静态方法都很好。

例如，采用一个简单的实用程序，例如将原始函数提升为幂——显然，您永远不需要在其中使用任何多态性。原始值是静态类型，数学运算定义明确且不会改变。这并不是说你永远不会遇到有两种不同的 实现，而且在不重写所有客户端代码的情况下无法在它们之间切换的情况。

（讽刺关闭）

如果只加载一个接口的一个实现，现代 JVM 非常擅长内联小调用。除非您已经分析了您的代码并且知道将您的实用程序分派到接口是一种开销，否则您没有理由不将您的实用程序方法放入一个可以根据需要进行更改的接口中。