静态类非常有用，有一席之地，例如库。

我能提供的最好的例子是. net Math类，它是一个包含数学函数库的系统名称空间静态类。

这就像任何其他事情一样，使用正确的工具来完成工作，如果没有的话，任何工具都可以滥用。

盲目地认为静态类是错误的，不要使用它们，或者说“只能有一个”或没有，都是错误的，就像过度使用它们一样。

c#。Net包含许多静态类，就像Math类一样。

因此，只要正确实现，它们就非常有用。

我们有一个静态TimeZone类，它包含许多业务相关的时区函数，不需要像Math类那样创建多个类实例，它在静态类中包含一组全局可访问的TimeZone相关函数(方法)。

对于c# 3.0，扩展方法可能只存在于顶级静态类中。

如果你使用代码分析工具(例如FxCop)，如果一个方法不访问实例数据，它会建议你将该方法标记为静态。其基本原理是有性能增益。CA1822 -将成员标记为静态。

这更像是一个指导方针，而不是规则，真的……

当我希望使用函数而不是类作为重用单元时，我已经开始使用静态类。以前，我对静态类非常反感。然而，学习f#让我从新的角度看待它们。

这是什么意思呢?好吧，比如说在编写一些超级DRY代码时，我最终得到了一堆只有一个方法的类。我可能只是将这些方法拉到一个静态类中，然后使用委托将它们注入到依赖项中。这也可以很好地使用我选择的依赖注入容器Autofac。

当然，直接依赖静态方法通常仍然是有害的(有一些无害的用途)。

我只对辅助方法使用静态类，但随着c# 3.0的出现，我更愿意为这些方法使用扩展方法。

我很少使用静态类方法，原因与我很少使用单例“设计模式”相同。

这是自面向对象开发开始以来另一个古老但非常热门的问题。 当然，使用(或不使用)静态类的原因有很多，其中大多数已经在大量的答案中涵盖了。

我想说的是，我让一个类是静态的，当这个类在系统中是唯一的并且在程序中有它的实例是没有意义的。但是，我将这种用法保留给大型类使用。我从来没有将MSDN示例中这样的小类声明为“静态的”，当然，也没有将成为其他类成员的类。

我还想指出，静态方法和静态类是两种不同的东西。在已接受的答案中提到的主要缺点是针对静态方法。静态类提供了与普通类相同的灵活性(涉及属性和参数)，其中使用的所有方法都应该与类存在的目的相关。

在我看来，静态类候选的一个很好的例子是“FileProcessing”类，它将包含与程序的各种对象相关的所有方法和属性，以执行复杂的FileProcessing操作。拥有这个类的多个实例几乎没有任何意义，而静态将使程序中的任何东西都可以随时使用它。