c# - 何时在 C# 中使用静态类

Question

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





Class with single method — best approach?

(15 个回答)


6年前关闭。




这是什么 MSDN has to say under When to Use Static Classes :

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

Use a static class as a unit of organization for methods not associated with particular objects. Also, a static class can make your implementation simpler and faster because you do not have to create an object in order to call its methods. It is useful to organize the methods inside the class in a meaningful way, such as the methods of the Math class in the System namespace.

对我而言，该示例似乎并未涵盖静态类的许多可能使用场景。过去，我将静态类用于相关函数的无状态套件，但仅此而已。那么，在什么情况下应该(也不应该)将类声明为静态？

Answer 1

我在较早的 Stack Overflow 回答中写下了我对静态类的想法:
Class with single method -- best approach?

我曾经喜欢充满静态方法的实用程序类。他们对辅助方法进行了很好的整合，否则会导致冗余和维护 hell 。它们非常易于使用，无需实例化，无需处理，只需触发'n'forget。我想这是我第一次在不知情的情况下尝试创建面向服务的架构——许多无状态服务只是完成了他们的工作，没有别的。然而，随着系统的发展，龙即将到来。

多态性

假设我们有方法 UtilityClass.SomeMethod ，它很高兴地嗡嗡作响。突然间，我们需要稍微改变一下功能。大多数功能是相同的，但我们必须更改几个部分。如果它不是静态方法，我们可以创建一个派生类并根据需要更改方法内容。由于它是静态方法，我们不能。当然，如果我们只需要在旧方法之前或之后添加功能，我们可以创建一个新类并在其中调用旧的类 - 但这太糟糕了。

接口(interface)问题

出于逻辑原因，不能通过接口(interface)定义静态方法。因为我们不能覆盖静态方法，所以当我们需要通过它们的接口(interface)传递静态类时，静态类是无用的。这使我们无法将静态类用作策略模式的一部分。我们可能会通过 passing delegates instead of interfaces 修补一些问题.

测试

这基本上与上面提到的界面问题密切相关。由于我们交换实现的能力非常有限，我们也很难用测试代码替换生产代码。同样，我们可以将它们包装起来，但这需要我们更改大部分代码，以便能够接受包装器而不是实际对象。

培养 Blob

由于静态方法通常用作实用方法，而实用方法通常具有不同的用途，我们很快就会得到一个充满非连贯功能的大类——理想情况下，每个类在系统中都应该有一个单一的用途。只要它们的目的明确，我宁愿有五倍的类(class)。

参数蠕变

首先，这个可爱而天真的静态方法可能只需要一个参数。随着功能的增长，添加了几个新参数。很快就会添加更多可选参数，因此我们创建方法的重载(或仅添加默认值，使用支持它们的语言)。不久，我们就有了一个接受 10 个参数的方法。只有前三个是真正需要的，参数 4-7 是可选的。但是如果指定了参数6，7-9也需要填写...如果我们创建一个类的目的是做这个静态方法所做的事情，我们可以通过在构造函数，并允许用户通过属性设置可选值，或同时设置多个相互依赖的值的方法。此外，如果一个方法已经发展到这种程度的复杂性，它很可能无论如何都需要在它自己的类中。

要求消费者无故创建类的实例

最常见的论点之一是:为什么要求我们的类的使用者创建一个实例来调用这个单一方法，而之后却不再使用该实例？在大多数语言中，创建一个类的实例是一个非常便宜的操作，所以速度不是问题。向消费者添加额外的一行代码是一种低成本，可以为 future 更易于维护的解决方案奠定基础。最后，如果您想避免创建实例，只需为您的类创建一个单例包装器，以便轻松重用——尽管这确实要求您的类是无状态的。如果它不是无状态的，您仍然可以创建处理所有内容的静态包装器方法，同时从长远来看仍然为您提供所有好处。最后，您还可以创建一个类来隐藏实例化，就好像它是一个单例一样:MyWrapper.Instance 是一个只返回 new MyClass(); 的属性。

只有西斯交易绝对值

当然，我不喜欢静态方法也有异常(exception)。不会造成任何膨胀风险的真正实用程序类是静态方法的极好案例 - 以 System.Convert 为例。如果你的项目是一次性的，不需要 future 的维护，那么整体架构真的不是很重要——静态或非静态，并不重要——然而，开发速度很重要。

标准，标准，标准!

使用实例方法不会阻止您也使用静态方法，反之亦然。只要差异化背后有推理，并且是标准化的。没有什么比查看具有不同实现方法的业务层更糟糕的了。