在什么情况下，静态方法是一种好的做法？

Question

我已阅读以下讨论：

如果私有帮助器方法可以是静态的，则它们应该是静态的；如果它们的类没有成员变量，则所有方法应该是静态的。

似乎人们通常会接受静态方法，但由于以下两个原因，对此有些怀疑：

1. 他们很难测试。
2. 他们违反了OO原则。（一个人说，它们是函数，而不是方法。）

最可接受的静态方法是 私有静态 方法。但是，为什么为什么根本不存在静态方法呢？在什么情况下，它们是最优先采用的方法？

Answer 1

静态方法本身并不难测试。问题在于， 调用 静态方法的其他代码很难测试，因为您不能替换静态方法。

我认为静态的方法都很好既可以当它们是私有的 或 当他们是“实用”的方法-
例如，做串逃跑。当您对要在测试中模拟或替换的事物使用静态方法时，就会出现问题。尽管通常情况下依赖注入是一种更好的方法，但工厂方法 也 可能很有用-
再次，它部分取决于您是否希望能够替换测试中的功能。

至于不是“ OO”-并不是用普通的OO语言编写的所有内容都必须是“纯” OO。有时，非OO路由更实用，并且导致代码更简单。埃里克·利珀特（Eric
Lippert）撰写了一篇很棒的博客文章，很遗憾，我现在找不到。但是，这篇文章中有一条相关的评论。它讨论的是扩展方法而不是静态方法，但是原理是相同的。

扩展方法经常被批评为“不够面向对象”。在我看来，这似乎是在把马车放在马的前面。OOP的目的是为由大型团队编写的大型软件项目的结构提供指导，这些团队不需要了解彼此工作的内部细节即可提高工作效率。C＃的目的是成为一种有用的编程语言，使我们的客户能够在我们的平台上高效工作。显然，OOP既有用又受欢迎，因此，我们试图简化以C＃编写OOP样式的程序。但是C＃的目的不是“成为一种OOP语言”。我们会根据功能是否对客户有用来评估功能，不是基于它们是否严格符合使语言成为面向对象的某种抽象学术理想。只要我们能够制造出使客户受益的一致，有用的产品，我们就会愉快地从oo，功能，过程，命令性，声明性等方面获取想法。