静态类被认为是不好的做法吗？几天前我读了一篇关于这个的文章（找不到它，抱歉），它基本上说拥有静态类（尤其是那些“帮助”类）通常是错误代码的标志。这是否正确，如果正确，原因是什么？
【问题讨论】：
标签： static-classes
我认为一般的论点是反对在静态类中保持可变状态，并且基本上将它们用作全局变量。静态类中的静态辅助方法没有任何问题。
至于为什么全局变量不好，我敢肯定，在这里和谷歌之间，你会找到数百万页和博客文章。
【讨论】：
滥用静态类可以被认为是不好的做法。但任何语言功能的滥用也是如此。
我没有区分只有静态方法的非静态类和静态类。它们实际上是相同的，除了静态类允许编译器强制执行开发人员意图（不实例化此类，访问其功能的方便语法，etc）。
正如您所说，“Helper”类的激增可能会给您带来麻烦（设计、可维护性、可读性、可发现性、其他能力......）。这里没有争论。但是你能说“Helper”类从不合适吗？我怀疑。
确实，负责任地使用静态类可以为您的代码带来很多好处：
Enumerable 静态类提供了一组我们大多数人都喜欢的扩展方法。它们是一组逻辑功能/业务逻辑，与任何特定类型的实例无关。所以不，一般来说这是不错的做法。明智地使用它们...
【讨论】：
这是否意味着“使用静态类是错误的”（在这种情况下文章不正确）或“静态类经常出现在编写糟糕的代码中”（在这种情况下，并不是说静态类本身就是不好的，但它们有时会被错误地使用）
静态函数比非静态函数更高效，因为您无需创建对象实例即可使用它们或将“this”指针传递给方法调用。
使用静态类来保存全局变量是另一回事 - 在这种情况下，基本规则不是“静态不好”，而是“全局不好”。
【讨论】：
我在我的代码中一直使用静态实用程序类来处理那些经常被调用但很难实例化的方法。一个示例是一个简单的日志记录类，例如：
public static class Logging
{
public static UpdateAction(int id, object data)
{
SqlConnection connection = new SqlConnection("conn string from config file");
// more logic here...
}
}
现在，我从来没有让这些类和方法存储任何类型的全局状态，因为这会导致巨大的并发问题，而且通常只是糟糕的设计。
所以不要避免使用静态类，只是避免让这些静态类保持某种全局状态。
【讨论】：
这里有一些 google 测试博客文章的链接，这些文章介绍了为什么静态方法会损害代码的可测试性，以及为什么静态方法（这是静态类的坏部分）会引入各种可能令人惊讶的耦合和交互组件之间。
【讨论】：
您需要一个实用程序类，其中所有方法都是静态的。在这种情况下，如果您将类设为静态，则它清楚地表明了您的意图。至少在 C# 中，静态类中不能有非静态方法。
【讨论】：
不，这并不完全正确。
有很多函数不是特定于对象实例的，并且不需要状态。例如考虑“数学”函数。
几乎所有语言都有类似的内容：
y = Math.round(x);
所以'round'函数是静态的。如果你疯了，你可以为 (C#) 之类的东西辩护：
class RoundFunction<T> : GeneralMathFunction<T>
{
public override T Operate (params object[] variables) {
..
}
}
但是，恕我直言，这样做会有点奇怪。
当然，有时静态函数过多是出现问题的迹象，但在合理的范围内，它并不“坏”。
【讨论】：