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

Question

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

假设方法总是有凝聚力的，在哪里可以使用公共静态方法？这些方法在 Java 和 .NET 之间是否有所不同（也就是在一种方法中比另一种更容易接受）？

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

Answer 1

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

我将静态方法用于具有很少/没有依赖关系以及定义明确的输入/输出的实用程序方法。

Answer 2

静态方法通常不应该：

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

相反，纯函数（即没有副作用）是好的静态方法。

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

Answer 3

我想说在简单的工厂中使用它们是公平的，比如返回包含静态方法的类型的场景。说如果：

string.Empty;

那么是合法的静态属性：

string.GenerateRandomString();

是合法的静态方法。然而即便如此，我也可以看到纯 OO 程序员可能更喜欢 StringFactory 或 RandomStringGenerator 类，但我想这完全取决于你在哪里画线。

Answer 4

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

Answer 5

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

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

附带说明：静态/共享方法稍微快一些，我记得它们在 CLR 中的实现与 OOP 无关，并且不允许在与 OOP 语言（至少 .NET）中的设计缺陷有关的接口中实现Java 固有的 -在这里讨论。

Answer 6

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

我相信您引用的帖子中给出的具体建议与静态方法所在的位置有关 - 而不是反对使用静态方法的建议。

Answer 7

一种典型的用途是实现单例模式。