为什么静态类被认为是"类"和"引用类型"？

Question

我今天一直在思考C#和CIL类型系统,我开始想知道为什么静态类被认为是类.有很多方法他们不是真正的课程:

• "普通"类可以包含非静态成员,静态类不能.在这方面,类比结构更类似于静态类,但结构具有单独的名称.
• 您可以引用"普通"类的实例,但不能引用静态类(尽管它被视为"引用类型").在这方面,类比接口更类似于静态类,但接口具有单独的名称.
• 静态类的名称永远不能在类型名称通常适合的任何地方使用:您不能声明此类型的变量,您不能将其用作基类型,并且您不能使用它作为泛型类型参数.在这方面,静态类更像名称空间.
• "普通"类可以实现接口.再次,这使得类更接近结构而不是静态类.
• "普通"类可以从另一个类继承.

将静态类视为从System.Object派生也是奇怪的.虽然这允许它们"继承"静态方法Equals和ReferenceEquals,但是继承的目的是有问题的,因为无论如何你都会在对象上调用这些方法.C#甚至允许您在静态类上明确指定无用继承,但不允许在接口或结构上指定无用继承,其中对象和System.ValueType的隐式派生分别实际上有用.

关于features-of-features参数:静态类具有类的特征的子集,但它们也具有结构的特征的子集.所有使类与其他类型不同的东西似乎都不适用于静态类.

关于typeof参数:将静态类转换为新的不同类型并不妨碍它在typeof中使用.

鉴于静态类的纯粹奇怪性,以及它们与"普通"类之间的相似性的稀缺性,它们是不是应该被制成一种单独的类型而不是一种特殊的类？

Answer 1

就CLR而言,它是一个类.它基本上只是C#编译器中的语法糖.

我不认为在这里添加一个不同的名称会有任何好处 - 它们的行为大多类似于只有静态方法且无法构造的类,这通常是当我们从中移动时成为静态类的类C#1到C#2.

请记住,如果你想为它创建一个新名称,这可能意味着一个新的关键字......

Answer 2

你的问题是"我为什么要输入单词static class X而不是foobar X".答案是,因为程序员已经将"class"这个词与"有人为我写的一堆紧密封装的功能"相关联.巧合的是,它完全符合静态类的定义.

他们可能会使用名称空间,是的.这就是C++中发生的事情.但是术语"静态类"在这里有一个优势:它意味着一个更小,更紧密耦合的功能组.例如,你可以有一个名为Qt或boost :: asio的命名空间,但是一个名为StringUtils或KWindowSystem的静态类(从KDE借用一个).

Answer 3

是的，他们很奇怪。它们确实有一些类的行为，比如能够拥有（静态）成员变量，以及使用 public/private 限制对成员的访问。

我几乎在那里输入了“public/protected/private”，但显然 protected 没有意义，因为没有静态类的方法继承。我认为这样做的主要原因是因为没有实例，所以不能具有多态性，但这并不是继承的唯一原因。多态性很棒，但有时您只想借用基类的大部分功能并添加一些您自己的东西。因此，有时您会看到静态类切换为使用单例模式，以便它可以利用基类集的某些功能。在我看来，这是一种缩小差距的黑客尝试，它会让人感到困惑并引入了许多不自然的复杂性。另一种选择是聚合，

现在，静态类通常只是用作全局方法的替代品，即只提供功能而不绑定到任何实例的方法。OO 纯粹主义者讨厌任何自由/全局的任何概念，但如果您只需要功能，您也不希望有一个不必要的实例和对象漂浮，因此静态“类”提供了一个中间立场双方都同意的妥协。

所以是的，静态类很奇怪。理想情况下，如果可以将它们分解为自己的概念，提供灵活性和轻量级易用性，您可以从不需要绑定到实例的方法（我们现在拥有静态类） )，并将这些方法分组到容器中（我们现在也有），但也提供了定义一个基础实体的能力，它将从中继承方法（这是现在缺少的部分）。此外，如果它是一个与类分开的概念，那就太好了，正是出于您提出的原因，它只会让人感到困惑，因为人们自然希望类是具有可以创建和销毁的属性和方法的实例。