c# - 为什么接口(interface)不能包含类型？

Question

这让我在 C# 中遇到过一两次。我可以写这样的代码

class Node
{
    class Connection
    {
        public Connection(Node node, string label)
        {
            this.Node = node;
            this.Label = label;
        }
        public Node Node { get; private set;  }
        public string Label { get; private set; }            
    };

    IEnumerable<Connection> IncomingConnections() // ...
    IEnumerable<Connection> OutgoingConnections() // ...
}

但是如果我写

interface INode
{
    class Connection
    {
        public Connection(INode node, string label)
        {
            this.Node = node;
            this.Label = label;
        }
        public INode Node { get; private set; }
        public string Label { get; private set; }
    };

    IEnumerable<Connection> IncomingConnections();
    IEnumerable<Connection> OutgoingConnections();
}

编译错误

error CS0524: 'Connection': interfaces cannot declare types

我理解限制，但我感兴趣的是为什么。我当然可以在 C++“接口(interface)”中使用嵌套类型(这只是一个具有抽象成员的类，所以不足为奇)，而且显然在 Java 中也是可能的，请参阅 Interfaces Cannot Declare Type Issue C# 。那么既然C#从Java中学到了一些东西，为什么它在这方面有所欠缺(如果确实欠缺的话)？

(很抱歉，如果这个问题已经在其他地方得到解决。我也找到了 Interfaces cannot declare types 和 Why can't I put a delegate in an interface?，但它们似乎没有直接解决我的问题。)

编辑

我想我只是添加一个注释来说明在 Java 世界中，乍一看似乎是一个悬而未决的问题，即是否可以在接口(interface)中嵌套类。见 https://stackoverflow.com/a/9098321/834521 。我不认为我问为什么同样不能应用于 C# 是愚蠢的。

编辑

简要总结/引自 Framework Design Guidelines，第 2ed，第 4.9 节 pp115-117。

• 请使用嵌套类型，例如嵌套类型需要访问封闭类型的私有(private)成员。
• 不要使用公共(public)嵌套类型进行分组；为此使用命名空间。
• 避免公开嵌套类型，除非您真的知道自己在做什么。 (主要动机:显式创建嵌套类型会让技术水平较低的开发人员感到困惑。但是隐式创建，例如通过集合枚举器，是可以的。)
• 如果嵌套类型将在包含类型之外使用或实例化，则不要使用嵌套类型(这两者都主张嵌套类型独立于包含类型) .
• 不要用作接口(interface)的成员。

Answer 1

Why can't an interface contain types?

在深入探讨这个问题之前，让我澄清几件事。

首先，CLR 类型系统确实允许在接口(interface)内嵌套类型。完全有可能创建一个 C# 或 VB 版本或任何支持在接口(interface)内声明的接口(interface)、委托(delegate)、类、结构和枚举的明天版本，并且它将在现有 CLR 上运行。

其次，对于“为什么 C# 语言不实现功能 X？”形式的问题，我将向您提供我惯常的反驳。对于 X 的所有值，答案都是相同的。为了实现一个特性，必须:构思、设计、指定、实现、测试并交付给客户。如果这六件事中的任何一件没有发生，那么就没有特征。 功能 X 未实现，因为其中一件或多件事情没有发生。

第三，C# 编译器团队(我已经不在了)不必为不实现某个功能提供任何解释。功能需要花钱，预算是有限的，因此请求该功能的人有责任证明其 yield 相对于成本的合理性。

第四，“为什么”的问题很难回答，“为什么不”的问题更难回答。

所以，话虽如此，我会拒绝你的问题并用我可以回答的问题代替它:

Suppose this feature request had been proposed to the C# design team. What arguments would you have made against it?

• 该功能虽然在 CLR 中合法，但在 CLS 中不合法。 C# 中有很多功能在 CLS 中是不合法的，但是由于 CLS 指导明确不要在接口(interface)中嵌套类型，因为大多数语言不支持它，因此在 C# 中实现该功能本质上是鼓励人们编写不能在其他语言中使用的库。 提议的功能会助长不良的编程习惯。

• 嵌套类型具有三个主要优势。首先，他们可以访问其封闭类型的私有(private)成员。这对没有私有(private)成员的接口(interface)没有好处。其次，它们提供了一种方便的方式来包含外部类型的特定私有(private)实现细节。这对接口(interface)来说不是一个好处，接口(interface)可能没有私有(private)嵌套类型，并且根据定义没有实现细节。第三，它们提供了一种将一种类型与另一种类型关联起来的便捷方式；然而，这最好通过 namespace 来完成。

• 据我所知，没有其他人请求此功能。当有大量客户确实需要的功能时，我们不要花钱购买几乎没有人想要的功能。

• 实现该功能本身并不会以任何方式使语言更强大或更具表现力。

• 据我所知，实现该功能并不是实现某些更棒功能的垫脚石。该功能与任何其他“主题”无关。这是一个“完成主义”特征，消除了一个小的非正交性，不是一个有用的特征。

• 对于缺少该功能，有一个简单的解决方法；只需将嵌套类型设为顶级类型即可。

情况反对。如果没有人为该功能 提出案例，它在设计委员会 session 上的持续时间最多可能不会超过五分钟。您是否愿意为该功能提出案例？