Question

静态类被认为是不好的做法？几天前我读了一篇关于这个的文章（找不到，对不起），基本上说有静态类（特别是那些'帮助'类）通常是坏代码的标志。这是正确的，如果是的话，出于什么原因？

Answer 1

滥用静态类可被视为不良做法。但滥用任何语言功能也是如此。

我没有区分只有静态方法的静态类和静态类。它们实际上是相同的，除了静态类允许编译器强制执行开发人员意图（没有实例化此类，方便的语法来访问其功能，etc）。

正如你所说，“助手”课程的激增会让你陷入困境（设计，可维护性，可读性，可发现性，其他能力......）。这里没有争论。但是，您是否认为“帮助者”类从不是合适的？我对此表示怀疑。

事实上，负责任地使用静态类可以为您的代码带来很多好处：

Enumerable静态类提供了一组我们大多数人都喜欢的扩展方法。它们是一组逻辑的功能/业务逻辑，与任何特定类型的实例无关。
环境/上下文提供的服务：例如，记录，配置（有时）
其他人（我现在想不到的事情:)）

所以不，总的来说，这不是一种不好的做法。明智地使用它们......

Answer 2

我认为一般论证是反对在静态类中保持可变状态，并且基本上将它们用作全局变量。静态类中的静态辅助方法没有任何问题。

至于为什么全局变量不好，我相信在这里和谷歌之间你会找到关于它的五百万页和博客文章。

Answer 3

是否意味着“使用静态类是错误的”（在这种情况下文章不正确）或“静态类经常在编写错误的代码中找到”（在这种情况下，并不是说静态类本身是坏的，但他们有时使用不正确）

静态函数比非静态函数更有效，因为您不需要创建对象的实例来使用它们，也不需要将“this”指针传递给方法调用。

使用静态类来保存全局变量是另一回事 - 在这种情况下，基础规则不是“静态不好”，而是“全局变量很糟糕”。

Answer 4

不，这不是真的正确。

有许多函数不是特定于对象的实例，并且不需要状态。例如，考虑'数学'函数。

几乎所有语言都有：

y = Math.round(x);

所以'round'函数是静态的。如果你疯了，你可以争辩像（C＃）：

class RoundFunction<T> : GeneralMathFunction<T>
{
    public override T Operate (params object[] variables) {
        ..
    }
}

但是，恕我直言，你这样做会有点奇怪。

当然，有一段时间，太多的静态函数是出错的标志，但是，在合理的范围内，它并不是“坏”。

Answer 5

以下是一些谷歌测试博客文章的链接，说明为什么静态方法会损害代码的可测试性，以及为什么静态方法（静态类的坏部分）会引入各种可能令人惊讶的耦合和交互组件之间。

how to think about oo

singletons

static-methods-are-death-to-testability

Answer 6

有些需要你有一个Utility类，其中所有方法都是静态的。在这种情况下，如果你使类静态，它清楚地表明你的意图。至少在C＃中，你不能在静态类中使用非静态方法。

Answer 7

我在我的代码中一直使用静态实用程序类，这些方法经常被调用，但实际上很难实现。一个例子是一个简单的日志类，如：

public static class Logging
{
  public static UpdateAction(int id, object data)
  {
     SqlConnection connection = new SqlConnection("conn string from config file");
     // more logic here...
  }
}

现在，我从来没有让这些类和方法存储任何类型的全局状态，因为这可能导致巨大的并发性问题，并且通常只是糟糕的设计。

所以不要避免使用静态类，只是避免让那些静态类保持某种全局状态。

你应该避免静态课吗？

7 个答案: