什么时候应该使用公共静态方法

Question

有很多人反对使用“公共/私人”静态方法。我一直在寻找，没有运气，并试图找到任何倡导善用静态方法的人。

假设方法始终是Cohesive，哪些是使用公共静态方法的可接受区域？这些方法在Java和.NET之间是否有所不同（又称它在一个方面更容易被接受）？

最近这篇SO帖子引起了我对这个话题的愤怒/兴趣。

Answer 1

如果可以将该方法视为一个单元，则使用公共静态方法，并且可以单独进行有效测试。在使用静态方法的类型上实现依赖注入或模拟很难。

我对实用程序方法使用静态方法，几乎​​没有依赖关系，并且定义良好的输入/输出。

Answer 2

通常的静态方法不应：

• 访问其参数之外的任何状态（因为这会导致难以改变的耦合）
• 修改其参数（因为如果是，为什么它不是该参数的实例方法？）

相反，纯函数（即没有副作用）可以产生良好的静态方法。

当然，这不应该被视为绝对的教条。

Answer 3

我认为在简单的工厂中使用它们是公平的，其中返回了保存静态方法的类型。如果：

，这并不是一个巨大的飞跃

string.Empty;

是合法的静态属性然后：

string.GenerateRandomString();

是一种合法的静态方法。然而，即便如此，我也可以看到纯OO程序员可能更喜欢StringFactory或RandomStringGenerator类，但我想这一切都取决于你绘制线的位置。

Answer 4

将方法标记为静态告诉使用者您不会更改传递给方法的任何对象的状态。静态方法应对传递的参数执行操作，不应依赖任何内部字段。

我相信你引用的帖子中给出的具体建议是关于静态方法的位置 - 而不是使用静态方法的建议。

Answer 5

一个典型的用法是实现Singleton模式。

Answer 6

我将静态/共享用于不属于该类实例的方法，或者我正在更新“共享”变量（请记住使它们的线程安全）。

通常，这意味着我最终将这些方法放在包含它们的不同“Manager”类中，我将构造函数标记为私有，以确保它们无法实现。

旁注：静态/共享方法是slightly faster，我记得他们在CLR中的实现是非OOP相关的，并且在接口中不允许这与OOP语言中的设计缺陷有关（至少.NET）Java固有的 - Discussed Here。

Answer 7

静态方法与全局对象实例上的实例方法具有相同的语义。除非您对全局对象实例感到满意，否则您不应该使用静态方法。也就是说，这在很大程度上取决于具体情况。有时候，讨厌的黑客行为是正确的。