什么时候在C＃中使用静态类

这个问题已经在这里有了答案：

• 单一方法上课-最佳方法？ 14个答案

这是MSDN在“ 什么时候使用静态类”下必须说的 ：

static class CompanyInfo { public static string GetCompanyName() { return "CompanyName"; } public static string GetCompanyAddress() { return "CompanyAddress"; } //... }

对于与特定对象无关的方法，请使用静态类做为组织单位。 一样，静态类可使您的实现更简单，更快捷，由于您没必要建立对象来调用其方法。 以有意义的方式组织类内部的方法（例如System名称空间中Math类的方法）颇有用。

在我看来，该示例彷佛并未涵盖静态类的不少可能的使用场景。 过去，我已经将静态类用于相关功能的无状态套件，可是仅此而已。 那么，在什么状况下（也不该该）将类声明为静态？

---

#1楼

静态类很是有用，而且有位置，例如库。

我能够提供的最佳示例是.Net Math类，这是一个包含数学函数库的System命名空间静态类。

就像其余任何事情同样，使用正确的工具完成工做，不然，任何事情均可能被滥用。

彻底否认静态类是错误的，不要使用它们，或者说“只能有一个”或没有，与过分使用它们同样是错误的。

C＃.Net包含许多与Math类同样使用的静态类。

所以，若是实施正确，它们将很是有用。

咱们有一个静态TimeZone类，其中包含许多与业务相关的时区函数，所以无需建立该类的多个实例，就像Math类同样，它在静态类中包含一组全局可访问的TimeZone实现的函数（方法） 。

---

#2楼

对于C＃3.0，扩展方法只能存在于顶级静态类中。

---

#3楼

我仅将静态类用于辅助方法，可是随着C＃3.0的出现，我宁愿将扩展类用于这些方法。

因为不多使用单例“设计模式”的相同缘由，我不多使用静态类方法。

---

#4楼

我在较早的Stack Overflow答案中写下了对静态类的想法： 使用单一方法的类-最佳方法？

我曾经喜欢用静态方法填充的实用程序类。 他们对辅助方法进行了很好的合并，不然将致使冗余和维护麻烦。 它们很是易于使用，无需实例化，无需处理，只是忘了忘了。 我想这是我第一次尝试建立面向服务的体系结构-许多无状态服务只是完成了本身的工做而已。 可是，随着系统的发展，巨龙将会来临。

多态性

假设咱们有一个方法UtilityClass.SomeMethod，它愉快地响起。 忽然，咱们须要稍微更改功能。 大多数功能是相同的，可是咱们仍然必须更改几个部分。 若是不是静态方法，咱们能够制做一个派生类并根据须要更改方法的内容。 因为它是静态方法，所以不能。 固然，若是咱们只须要在旧方法以前或以后添加功能，则能够建立一个新类并在其中调用旧类-但这很麻烦。

界面问题

出于逻辑缘由，没法经过接口定义静态方法。 并且因为没法覆盖静态方法，所以当须要经过它们的接口传递静态类时，静态类是无用的。 这使咱们没法将静态类用做策略模式的一部分。 咱们能够经过传递委托而不是接口来修补一些问题。

测试中

这基本上与上面提到的界面问题并存。 因为咱们交换实现的能力很是有限，所以咱们也很难用测试代码替换生产代码。 一样，咱们能够将它们包装起来，可是这将要求咱们更改代码的大部份内容，以便可以接受包装器而不是实际的对象。

福斯特斑点

因为静态方法一般用做实用程序方法，而实用程序方法一般具备不一样的用途，所以咱们很快就会获得一个充满非一致性功能的大型类-理想状况下，每一个类在系统中应具备一个单一的用途。 只要他们的目的获得明肯定义，我宁愿选择五倍的课程。

参数蠕变

首先，这个可爱又天真的静态方法可能只须要一个参数。 随着功能的增加，添加了两个新参数。 不久便添加了可选的其余参数，所以咱们建立了该方法的重载（或仅添加默认值（使用支持它们的语言））。 不久，咱们有了一个采用10个参数的方法。 实际上只须要前三个，参数4-7是可选的。 可是，若是指定了参数6，则还必须填写7-9。。。若是咱们建立一个类的惟一目的是执行此静态方法所作的工做，则能够经过在类中接受所需的参数来解决此问题。构造函数，并容许用户经过属性或方法设置可选值，以同时设置多个相互依赖的值。 一样，若是方法变得如此复杂，那么极可能不管如何它都必须属于本身的类。

要求消费者平白无故地建立类的实例

最多见的论据之一是：为何要求咱们的类的使用者建立一个实例来调用该单一方法，而以后却再也不使用该实例？ 在大多数语言中，建立类的实例是很是便宜的操做，所以速度不是问题。 向消费者添加额外的代码行是为未来奠基更易于维护的解决方案奠基基础的低成本。 最后，若是要避免建立实例，只需建立类的单例包装便可，以方便重用-尽管这确实要求类是无状态的。 若是不是无状态的，您仍然能够建立处理全部内容的静态包装器方法，而从长远来看仍然能够为您带来全部好处。 最后，您还能够建立一个类来隐藏实例化，好像它是单例同样：MyWrapper.Instance是一个仅返回new MyClass();的属性new MyClass();

只有西斯（Sith）处理绝对

固然，我不喜欢静态方法也有例外。 真正的实用程序类不会形成任何膨胀的风险，对于静态方法来讲就是个很好的例子-以System.Convert为例。 若是您的项目是一次性的，对未来的维护没有要求，那么整体架构真的不是很重要-静态仍是非静态，都没有关系-可是开发速度确实如此。

标准，标准，标准！

使用实例方法并不妨碍您也使用静态方法，反之亦然。 只要差别化背后有其合理性并被标准化便可。 没有什么比查看遍及着不一样实现方法的业务层更糟糕的了。

---

#5楼

我使用静态类做为定义给定类型的对象能够在特定上下文中使用的“额外功能”的一种方式。 一般，它们原来是实用程序类。

除此以外，我认为“将静态类用做与特定对象无关的方法的组织单位”。 很好地描述它们的预期用途。